#gdevelop 5

[dfilitto]

Aprenda a Subir Escada em Jogo de Plataforma - GDevelop 5 

O post Aprenda a Subir Escada em Jogo de Plataforma – GDevelop 5 ensina como voce poder subir escadas em jogos de plataforma na game engine GDevelop 5 Aprenda a Subir Escada em Jogo de Plataforma – GDevelop 5  Quem ensina essa super dica é nosso amigo Ian do canal Criar Um Game. Super dicas Se inscreva em nosso canal e compartilhe as matérias que gostar com os seus colegas. Participe dos…

[clarkpadmore]

An entry in the GDevelop BIG Game Jam #5 / "Unstable"

Belfry Bat, a 2-20 minute bat flying game about reaching the top of a church tower. Now available for browser and desktop at Itch.io.

[donnatang]

Week 5

This week 5 lecture revealed key insights about GDevelop’s strengths and limitations for game development. I learned that it’s ideal for small-scale, 2D projects like platformers or puzzles but struggles with complex genres (RPGs, FPS). The emphasis on iterative design stood out—focusing on a core mechanic (e.g., randomized attacks using variables) and refining it through playtesting is more effective than overambitious scopes.

Technically, I discovered three variable types:

Object variables (e.g., enemy health),

Scene/global variables (e.g., score),

Arrays (for dynamic lists like difficulty settings).

The lecture also covered clever 2D tricks, like parallax scrolling for depth and isometric faux-3D using layered sprites. For combat, hitbox/hurtbox systems ensure responsive melee mechanics, while Physics 2.0 (experimental) allows tweaking friction, bounce, and gravity.

A key takeaway was design discipline: use GDevelop’s simplicity to prototype quickly, but transition to engines like Unity/Unreal for advanced projects. The lecture’s examples—like randomizing attack animations or camera-follow systems—showed how small details elevate gameplay without complex code.

[evnsparks]

Asteroids - Development Post

Hello and welcome to another week of posts. This post focuses on the asteroid game development. Taking lessons from the previous development cycle a quick prototype method was adopted allowing for greater experimentation within GDevelop and a more complete prototype. The focus on moment-to-moment gameplay development should also lead to a better player experience in playtesting.

Keeping A Nice and Tidy Workspace

Having programmed before, one of the first concerns for the project considering the large number of features to be added is the readability of code. This is because code that is hard to read can make it more difficult to resolve bugs or tweak features in the future (Fernandez, 2020). To resolve this, I would make extensive use of the events group function of GDevelop. This proved to be sufficient to keep code tidy and readable.

(Using Event Group Function in GDevelop)

However, even with this it still led to difficulties in readability with more code than anticipated needing to be added. To resolve this in future I could further break down groups to cover sub sections of a main feature. Another method is to use the commenting function to make it easy to determine what the features do in future as at times it became difficult to determine what each feature did between larger time off of coding that feature.

(GDevelop Example)

Prototype, Test, and Tweak!

A lesson learnt from the last development phase was to focus on quick and simple prototyping with plenty of playtests to tweak to a desired result. This process of prototyping saw great results for the asteroid game with many features being able to be implemented.

Planned to Implement for Prototype

Movement ability. (Implemented)

Primary weapon use. (Implemented)

Asteroid Basic. (Implemented)

Shop and Powerup. (Partially Implemented)

Develop Level 2 and Asteroid 2, slightly more complex. (Not Done)

Art and Sound Effects (Not Done)

Movement System

A large time sink last development cycle was the movement system, I decided this time round to keep it a little simpler with simplistic momentum in only one direction stiving for as close to or good enough than perfection. The goal for it was to be tricky and be a realistic space like feel with rocket-like propulsion.

Getting it to the right amount of speed was tricky as I was not sure how to implement a realistic momentum-based physic system in GDevelop (Something to investigate for the future). Using quick tweaks and testing I was able to get it feeling close enough to intended with a potential flaw to test is its difficulty to learn and control. However, once mastered was quite satisfying.

Perhaps something to look into the future is a cap to the speed to prevent out of control movement.

Implementing the shooting mechanic was very similar to the movement system and thus quick to implement requiring tweaking to adjust the fire-rate to replicate the difficulty of old equipment in a tough environment and set up players for an incentive to upgrade.

Reusing Old Assets to Save Time!

The mechanic of spawning material for the player to collect required a new sprite to be found. In previous game developments I often found myself searching a long time to find a specific asset that matched the look and feel I was after. Taking the quick prototype approach meant that such a method should not be taken unless it was integral to the player experience being tested for the prototype which in this case it was not. A solution to this was by using previous assets to serve the function required. This worked out well and made it easy to implement without too much time waste and is a method I will try to utilize further in any prototyping. Through this it allowed more time to be spent on tweaking mechanics to be just right and did not detract from the player experience for the current prototype version.

(Using a previous asset for a different project)

All Things UI!

A large part of the prototype required the use of updatable text interfaces that can be updated to track the players quota as well as make the shop functional. This was not too tricky requiring the use of variables and works similarly to how it is implemented from my previous coding experience. Whilst Fullerton (2018) mentions making code quick and dirty focusing on functionality and getting the prototype working a problem did occur in the large number of variables that needed to be updated. I would often assign fixed numbers that would be tricky to edit or find later. A solution would be to use arrays or to find another method to track and update these variables.

(Lots of Variables!)

This would help to reduce certain times where tweaking many variables is needed. In implementing the text interface, I did end up finding the previous paper prototypes helped a lot in reducing wasted time implementing it via programming and resulted in an interface that was quite usable whilst being quick to implement.

(Paper Prototype)

(Actual Implmentation)

Buttons!

As part of making the shop I also learnt to experiment with buttons that are interactable. This was quite simple using the animation function to change what animation it would play based on the mouse position.

(Button Animation)

I also found great use with the free GDevelop assets to find assets quickly and implementing them easily.

(GDevelop Asset Store)

Out of Scope and Conclusion

Through the quick prototyping method, I was able to experiment with many facets of GDevelop this time round and made a good couple of levels to playtest. I was able to explore the use of and creation of sprites as well as how to make UI elements. Unfortunately, due to time constraints I was not able to really implement any artistic element for the prototype and there was not any time to experiment with implementing sound effects. Furthermore, mechanics such as a harder asteroid in level 2 and a fully functioning shop were not implemented. However, there is “enough game” to test with and I am sure there will be a lot more to talk about this time round after playtesting. Looking forward to it!

References

Fernandez, S. V. (2020, November 12). Code readability matters. The Guardian. https://www.theguardian.com/info/2019/jan/29/code-readability-matters

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Fourth edition. http://dx.doi.org/10.1201/b16671

[intel-core-i0]

Mistakes, Comprehension and a New Direction™

Time to actually produce the second GDevelop game. I've learned a few lessons after the last attempt that I want to apply to this one:

1) Reduce scope

The biggest problem that plagued my attempt at creating a platformer was the large scope, trying to incorporate environmental storytelling into a hand-built word. This was not an achievable level of quality in the time allocated for the task, and deviated away from the seeds of gameplay I identified in my first post on ChronoKnight. For this reason, Astro Annihilation will focus on moment to moment gameplay instead of complex level design, and will use things such as enemy spawn tables and duplicated assets to reduce the development time. This relates to the IGB120 Week 5 Lecture on understanding the possibilities and limitations of GDevelop, especially the advice of finding a simple scope that is easy to iterate on.

2) Playtest earlier and more

It will be important for Astro Annihilation to be playtested more than ChronoKnight, especially in the early phases. The reduced scope of the game will aid with this, as having a smaller amount of work for each gameplay moment will allow more to be produced before a reasonable timeframe for playtesting arrives.

3) Take on a more iterative approach

Further on this point, Astro Annihilation would benefit from a more iterative approach - things such as enemies and movement are easier to tweak and adjust than a hard-coded level design, meaning more action can be taken on player feedback.

Hopefully, following this new design strategy, it will be more feasible to complete an appropriate quality game within the timespan allocated. Sorry though, this was another dry post, but I think do it's an important one.

[eddieripps]

what do you use to like animate /create your games?

hiiii, I use gdevelop 5 as the actual game creation engine. the initial post with the game opening and natalie's "character card" are both animated frame by frame in pixlart, a web based pixel art program. it's also what I use to create my sprites bc I'm always looking for simplicity lmao

[castlesconundrum]

what will the first demo have?/other stuff -[Pizza Tower Clone]

(SORRY FOR BEING GONE FOR A LITTLE WHILE, MOTIVATION IS A BIG STRUGGLE FOR ME SO POSTS WILL BE FEW AND FAR BETWEEN.) -Drew

ight so, before i get into the topic of this post, id just like too say:

I GAVE MIKE A GUN !!

as of now mike/the player can: double jump, dash, run, walk (duh) and shoot. (also another machinic but I'm not going to reveal it here mwaahahahahahaha)

anyway, the first demo will have a tutorial, and 1-2 levels.

One of the 2 levels being called "medieval mania" being a castle/medieval themed level, the other level is not exactly in my mind, i was thinking of something called "ancient grease" a pun of "ancient Greece" it would be like ancient Greece but food themed(?) but that also seems too close to pizza tower, my game is inspired not a copycat, although the idea is kind of funny. Also, the first world of the game (or floor, as you climb a castle.) is time themed, so that could fit as well.

Anyway, i also made some enemies:

the ball with legs is called a "goober" its just the generic "Goomba/Cheese slime" enemy of the game, the next one is a spear guy, may call em spearies, they damage you if they run into you. Lastly is the knight, they drop swords from above (most likely going to redesign them as the sprites kind of lazy.) They also cannot be killed.

Anyway, before i go, heres a video of me in a test room messing around:

(Sorry for no sound idk my pc doesn't like recording Gdevelop 5 preview's sounds i guess?)

[steamboatops]

Important Decision, going to vote

Heya people, today I have something incredibly important that I would like to aim at the people interested in playing this game. It does mean sacrificing something or other.

The Question is: Do I move everything from this project over to Godot 3.5 (And by extension UWP)?

If the answer is yes, it does mean that everything will be restarted from the ground up, however this adds Xbox to the release roster, as well as Windows Store.

If the answer is no, it means nothing really changes in terms of the cycle, the only thing is the Xbox and Windows Store ports will be cancelled, as GDevelop 5 doesn't have UWP, lacking anything to port it to consoles.

I'll be throwing this question to everyone who wants to play, rather than making an unpopular decision. Granted using GDevelop wasn't the 10/10 decision I assumed it to be.

Do note that if the Xbox Port gets scrapped, Oswald will probably make an (non-monetised) appearance on the console anyway, though in other ways.

[vi-r-gamedev]

Assignment 3 Development

For the third assignment, I’ve teamed up with some classmates, and will be working on one of their games; Running out of Time. To introduce the game, It is a puzzle platformer, where the player encounters the ‘echo’ of their past self, which follows the path they’ve taken in previous levels.

To develop the prototype to a minimum level to playtest efficiently, we decided that the main focus would be in level design and creation, as the main mechanic of the echo depends heavily on the design of the levels and the relation to the previous level. Remaining conscious of the time required to play a significant enough portion of the game to effectively playtest, we decided to create a total of 15 levels, or 5 each. As each level is the size of one screen, maximum 2 scrolling horizontally, they are quite short, so we considered this to be a reasonable amount to develop.

To begin my development process, I brainstormed to come up with some mechanics to be implemented, which allow the game to remain varied, but still simple enough to develop. Since I have a team this time, I was able to come up with the slightly more complex concept of a wall jump and platforms which can move vertically, with the possibility of being desynced. It was my responsibility to code the moving platforms, which I was able to do rather easily with my knowledge of GDevelop object variables, and the inbuilt mathematics functions allowing for simple sine wave movement, with variables adjusting the amplitude of the wave and allowing for a platform offset.

Here's the code for that:

I was assigned the role of creating levels 11-15. To begin my process, I mapped out in photoshop the route the player would take through the level, including the position of any moving platforms, and ensuring the path overlapped with the previous levels’ in an interesting way to promote interaction with the main mechanic of the game. Following this, I simply built the levels in GDevelop, and played them to adjust for movement, jump distances, and to ensure they were beatable.

Here's one of the levels I made:

Also, since I was the member of the group with the most confidence in sprite editing/creation, I took on the role of artist for this project. The spritework my groupmate had used for the early prototype was effective, but lacking cohesion. In particular, they wanted to update the echo from a generic ghost into a more sinister reflection of the player. I took the player’s sprite, greyed it out to make it seem more like a ghoul, added bright orange eyes which stand out against the mainly grey background, and replaced its legs with a more ghostly trail to really communicate that detail. Additionally, I added an animation of red lines scrolling along the echo’s body, inspired by the green code lines used in the film The Matrix, to give it a touch of the futuristic, and to help it stand out even more on the screen. Given that I am not majorly involved in creating art usually, I think it turned out pretty good!

Here's the Echo sprite (not animated since uploading as a GIF gave me trouble, watch this space):

[owlzer]

Week 9 - Racer Post Mortem

Fullerton has made some interesting insights in conceptualisation. Where do our ideas and inspirations come from? They talk about how some people that are very inspirational to me such as Shigeru Miyamoto have used personal interests and their hobbies as an influential part of the game design. I feel I have taken my personal interests to heart in all of my mini-games sourcing my own creativity and game mechanics around them. Fullerton talk about Psychologist Mihaly Csikszentmihalyi who has broken up creativity into 5 stages: preparation, incubation, insight, evaluation and elaboration. The 'creative process' is described as a very fluid thing and we are encouraged to become involved in many aspects of life to fuel our preparation and incubation stages. Although I feel like I have slowed down quite a bit in life with the amount of activities I do, I am still able to draw from a wide range of experiences for inspiration. I have done girl guides, dance, travelled, played and instrument just to name a few. I am going on another trip this year and I will take creative advantage of it. From my experience making my one sheet and one page, I really want to challenge myself going forward to make something completely original and my own and I feel it will really challenge me to go through all 5 stages of creativity and will be very rewarding.

Digital prototyping has really become a main focus of making these mini-games. Game mechanics, aesthetics, kinesthetics and technology are four areas of investigation highlighted by Eric Todd.

Throughout my process, I feel that I have investigated game mechanics and aesthetics the most. However, I have greatly neglected kinesthetics and technology. Kinesthetics are describes as the 'feel' of the game (e.g. responsiveness and how controls feel). Although I unintentionally focused on this in my first game when I was working on my main grapple mechanic, this was overlooked in my other two games. In my racing game I just kept the original controls which I feel like was a mistake. Although it worked and did its job, I feel like more experimentation with the kinesthetics could have made the game feel more immersive. My interfaces in all of my games were also really bland. My racing game had a decent title screen but the score and game over screen were really lacking as they were very simple text. A more effective interface could have really added to the player experience.

My racer game is the one that I felt had the most potential. This is why I used it for my one sheet and one page. This game, more than the others has shown me the incredible values of playtesting. This is due to the great amount of improvement the game has gained from the feedback I have received. I don't think the game would have reached this potential without it and I will carry these thoughts with me as I continue my journey as a designer. This game also really challenged me as an artist as I had to draw in top-down view, a skill I have barley developed yet. It has shown me that I'm still very early in my art journey and to really practice drawing in different perspectives. Making a powerup for the first time was really fun and if I were to make Captain Sora's Sea Scurry I would really enjoy the challenge of making the other powerups I came up with. I think I have really improved as a coder and in using Gdevelop 5 as I am constantly researching how to code new things and use other parts of the program. Although the game is still very simple, it has really taught me a lot about the true value of each and every stage of the process. I hope from these experiences that it will help me grow into a game designer that can truly master digital prototyping and take these skills with me as I develop my own game with my partner.

References:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating

Innovative Games. ProQuest Ebook. Retrieved

from:  https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[dfilitto]

Aprenda a Rolar Dado com Valor Aleatório - GDevelop 5

O post Aprenda a Rolar Dado com Valor Aleatório – GDevelop 5 ensina como voce poder criar uma maneira de rodar dados com valores Aleatórios na game engine GDevelop 5 Aprenda a Rolar Dado com Valor Aleatório – GDevelop 5 Quem ensina essa super dica é nosso amigo Ian do canal Criar Um Game. Super dicas Se inscreva em nosso canal e compartilhe as matérias que gostar com os seus…

[clarkpadmore]

Good morning, everyone,

I hereby announce my intention to join the GDevelop "BIG" Game Jam #5. I will be personally unavailable until Monday the 27th. Showcases have been pre-scheduled.

That being said, my participation in this event will be significantly casual compared to previous events. This is the first game jam I've participated in since acquiring my employment at [the manufacturer], and I will be down 43.5 hours from the nine day development period.

I plan to make something nice and small for this competition. I can't wait to see what everyone creates!

Have a good week, — Clark Padmore

[wdzg-cygon]

Gdevelop 5 FPS Template progress

[kawaiicollectorinternet]

Platformer Elevator Pitch (Pt. 1)

My first project, as part of IGB120, will be a platformer made on the Gdevelop 5 engine; however, I need to develop the game throughout the concept stage and create an elevator pitch before the game can begin to be developed.

This week chapters 1 and 2 of "Game Design Workshop" clearly articulated the process to developing a playcentric game. Tracy Fullerton explained the importance of creating player experience objectives with solid gameplay interactions in mind, and how the core gameplay mechanics need to be well thought-out before development can even begin.

Fullerton illuminated that the most important aspect of a game is fun and engaging gameplay; if the player isn't enjoying the gameplay, they will discontinue playing. Fullerton then established that to ensure the gameplay keeps a player engaged a play centric design model needs to be implemented where the player experience is put at the heart of the design process. In order for a game to follow a playcentric design it is critical that prototypes are developed as soon as the core mechanics and player experience goals are devised to get player feedback, in the form of playtesters, as early in the design process as possible.

For my platformer I want the core mechanics to include movement, such as jumping, running, and double jumping; and the player experience goals to include encounters with enemies, physics puzzles, and hidden collectables.

References

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[dreammelter]

Speedrun Workshop Postmortem

I wanted to make a more detailed postmortem as I cleaned the project files up but I'll keep it simple today… If I take any longer, I'm sure to give up on it. (The year is ending so there's a lot of prep/wrap-up going on in other areas I'm responsible for. 🙃)

What I'll cover:

What was the project about? It's goals? It's products?

How did I approach it?

How did things change and why?

What did I like most of what I completed?

What did I wish I could complete?

What did I learn? (A LOT. But maybe make a more definitive list.)

What would be my tips/advice for next time?

(Project deliverables are up on GitHub.)

The One Day Workshop

I only vaguely remember what spurred the project and apparently don't have any journal entries for it either… so here's the gist of it!

My sister worked with City of Las Vegas/Strong Future to help teach some Office 365 basics. In July, she decided to start a small tech biz (now defunct) that offered more technical training. If I remember correctly, she asked if there was anything I'd like to offer, so I figured I could cover programming, 3D art, and game development. (I really just wanted an excuse to play with the things I liked lol.) The team at Strong Future took an interest in hosting the game development class, but they only had a small budget for it at the time. So we decided to host a workshop for middle and high school students on Nevada Day.

The idea was to introduce students to the process of game development as well as some careers and resources. Since the workshop would only last 5 hours, the students would follow along with the recreation of an arcade-like game. I originally wanted to require students have some experience with code since we'd be jumping right into a project. We decided to leave it open to those without it, though. I figured I could do a quick intro to scripting and wouldn't sweat it too much since students could either type-along or drag-and-drop the files.

The workshop had an additional constraint: the computers in the lab wouldn't be able to install any additional software, so I'd have to use a portable or web-based game engine. I've long held onto a list of game engines and dev resources, so finding one wasn't an issue. What was interesting, though, was seeing how some of them have changed over the years… Godot Engine was the first one that came to mind and the one I was sure I was going to go with, but I took a look at my old list anyway. Cocos2D was my second choice since I'd be able to use JavaScript and I was considering it for a future web project, but it required more setup and research than I was interested in bothering with. (The modern Cocos editor requires an install.) Defold, like Godot, doesn't require an install but I didn't want to write in Lua. (Read: I didn't want to relearn how to write Lua. I only have three months.) Game Maker, Construct, GameSalad, and GDevelop were some others I considered for their web versions and/or visual programming features, but I didn't want to force the students to sign up for anything.

So Godot it was. 😎 Long Live Open-Source.

We also named the workshop "Speedrun" some weeks later.

Expectation

The workshop needed three things: a prototype to remake, some slides, and a collection of resources the students could use and refer to later. I was also advised to create a printed handout students could follow along with.

There would also be 20 students at most.

I wanted to break down the five hours as such:

1 hour talking about the industry, careers, and development concepts

3 hours walking through the prototype

1 hour letting the students tinker and build their own levels

(I wrote a couple of different outlines with timestamps closer to the end of the project, too.)

I wanted to teach the students game dev was all about problem solving (and IID.) I'd pose a question or scenario, then walk them through the implementation. Once we built the base game, the students could use the extra resources to add to it however they pleased.

I also split up the 3 months of development time of this project:

1 month to get up to speed with Godot 4 and create a game prototype

1 month to polish the prototype and write up the written materials

1 month to polish the materials, practice the presentation, and prepare for the workshop day

Reality

So I ended taking two months trying to prototype. I briefly talked about it in the "mini postmortem" I included in the class handbook… In short: I tried out different game ideas to see what I could actually implement by the end of the first month. The second month rolled around so I started moving the desired game mechanics to a clean file… just for them to start falling apart. That's when I settled on just making a simple platformer. I used all of September and half of October putting the platformer prototype together, leaving two weeks to put the remaining documents together. Ended up skipping the handout, since I couldn't decide what to put on it… I had a couple different versions of the to-do lists I used to track progress of the game that I could use, but I wasn't sure just how much detail should be included for each task to actually be useful. I didn't complete the handbook in time for class either, so I spent an extra two-three days writing that up…

Dragging and dropping the scripts and resource files from the prototype came in super handy. Because, contrary to my expectation, 4 hours was not enough time to even get past the setup of the player character and tile map. I did not account for students who might not have had any experience with editors of any sort (and forgot to give them an actual tour of the engine. OTL) It wasn't the perfect presentation of "game dev as problem-solving" I hoped for… it was a scramble of remembering what to click and do next. I think the problem-solving sentiment still floats around in the docs and presentation… somewhat. But if there's anything I regret, it's that failure to effectively lead the students through the recreation of the prototype game. We were all pretty exhausted by the end. They said they learned a lot but I hope it didn't crush their interests in building games. 😭

I did spend about an hour and a half covering the industry and such (to my surprise. I wasn't sure I was going to have enough to say, but alas… we did. And it was just a debrief of the topics themselves.) I was also lucky that the students who came in later showed up at opportune times, when it was easy to get them up to speed.

I didn't complete the prototype, but we didn't get very far with the game in-class, either. Guess there's a bit of grace there… I was so worried I end up with a class full of students who were already so comfortable building games in the virtual worlds they hang out in. (But I only had one student who was actually enrolled in a game development program and he was just starting out. All of the students were.)

Reflections

All of that said… I think seeing the reality of how this went down was enlightening. When I get ideas they tend to be overly idyllic and lofty, so it was good to see the gritty, incomplete, and even a little ugly side of this. It was a nice reminder of how much effort goes into creating something that's really good. I mean… the burnout I got after rushing to get this together was 0/10… but the respect I gained for the craft went up 1000%. And seeing how much is available online: from support groups to free tools, the future of game dev will always be bright and exciting.

Part of my screw-up with the approach to teach the development part could have been alleviated if I knew we'd only tackle such a small scope in that time… I obviously couldn't have known how much we'd get through, but a back-up plan beyond "use the premade resources to speed things up" might have been useful in this case. Maybe I could have an alternate "lesson route" where I scaled back most of our goal.

Then again… I probably would've known this ahead of time if I actually practiced the full presentation with someone, rather than the dry run I did alone. 🤔 (One of those expectation vs. reality things.)

Favorite Things

I remember making my first digital game in Flash (though I have this sneaking suspicion there was something I used before it?) Godot's scene-structure was very reminiscent of it. I also liked that it meant you could structure you game basically as the way you see it, making it easy for students to conceptualize.

I also love that you can make tools for the engine using the same language you do to write gameplay code. The coin tool is probably my favorite thing, even though it's incomplete.

Wishes

I'd actually like to figure out what's going on with the double jump animation (which was working at first.) The player can double jump, the conditional block holding the animation just doesn't fire. (I think. I'd have to check the code again.)

It'd also be cool to get the coin tool to work properly in-editor.

Lessons Learned

You won't be able to fit absolutely everything into a project and you probably shouldn't try. 😆 Don't let your brain lie and say you can. Dipping into the longer list of "Nice to Haves" after finishing the "Must Haves" feels nicer than having a long list of "These things were supposed to be in the game--"

Conclusion

I'm gonna be 100% honest, I'm not sure I'd try to build a platformer on my own again. Maybe something closer to a visual novel, sure, but anything more than that? I'd probably enlist the help of some friends. (Especially a gameplay programmer. I'll stick to tools…🫠)

It's a stark position from the one I held as a teen building (fragments of) games… maybe it was the rush to get something together and the burnout that followed. Maybe it was the fact I was building something outside of my initial intention, so I didn't have the same "emotional attachment" I would for something more personal. I do primarily think it was the time constraint and the pressure to make something that I thought would be satisfactory for the students to start with. Sure, I can perform under pressure, but I can't say I do better work under it. And frankly, the pressure is only more bearable with a team, which I didn't have lol.

However, the most important thing is that I completed enough of what was required for this endeavor that I could see it as a success. It's not a smashing or career-changing one, but it's just big enough to be a meaningful experience. (For me and for the handful of students who made it.)

[eddieripps]

your art is so pretty! that snippet of the gameplay was so cool to see. I was wondering where you learned to code and what language you're using? i'd love to learn how to code and make something a fraction as good

hiiii :((( this is so sweet thank you so so much <33

as far as language goes, im in college for programming and compsci so I've learned like.. too many languages to keep track. the ones I use most are python and javascript though!!

for the game, it's built in a program called gdevelop 5 which is basically like scratch just like. adult scratch. imagine lego duplo vs legos. same concept just more shit to it. and it's javascript compatible if I ever hit a roadblock and need to write something out. i find it to be most similar to visual basic in terms of actual use though, if you've ever used microsoft visual studio

i would probably get more control over it / be able to make it less messy if I rebuilt it entirely in javascript from the ground up but also its a silly pixel game for my favorite show. it's saved on my computer as "yellerjackers". i simply wanted it to work enough for stupid posts on my tumblr and I achieved that no shame in my game (ba dum tss.. anyone? hello? is this thing on?)

but if you ever do wanna just hop into something without having to spend an entire semester learning a programming language, gdevelop is great. they've got tutorial games you can follow along with to teach you basic framework as well.

im a guy who hates when creativity is limited by skill and knowledge gap (comes with having dyscalculia and majoring in a math based field) so I'm always gonna encourage using your resources. doesn't matter as long as you have fun with it!