#learning godot and coding is going well though | Explore Tumblr posts and blogs

femboycatofmystery · 1 year ago

Text

So my post about how you should draw (YOU SHOULD DRAW!) blew up beyond any precedent since my return to tumblr and someone in the FRANKLY KIND OF TERRIFYING NUMBER OF REBLOGS mentioned downloading a free DAW to make music and that got me thinking,

HOBBY SOFTWARE MEGAPOST GO

All of the below software is free to use, and most of it is Open Source (which is its own thing I recommend learning about, its entire existence and success gives me hope for humanity) so GO GET SOME TOOLS! Make things like nobody's watching and then SHOW IT TO THEM ANYWAY! Or don't! Even if you hide your work from the world (lord knows I do!!!) you will have created something! And it feels amazing to create something!

VISUAL ARTS:

Inkscape: Adobe Illustrator replacement, pretty solid if a bit quirky.

Krita: Painting software, if anything slightly overpowered and sometimes more complicated than you want, but can do bloody anything including advanced color management. A wonderful tool.

Blender: You have probably heard it is super hard to use. This is CONDITIONALLY true. Because the developers are working day and night to improve everything about it it's always getting better and now like, 80% of the hardness is just because 3D is hard. Aside: Blender Grease Pencil - A subsystem in Blender is concerned with 2D animation and it is. Surprisingly good. Some annoying conventions but totally possible to literally make professional traditional 2D animation.

MUSIC:

LMMS: A free and open source DAW that can do a lot, except use most modern VST plugins. The practical upshot of this is that if you are just starting out with music it is totally serviceable but over time you might start to long for something with the ability to load hella plugins. (I'm currently trying out Reaper which has a long free trial and is technically nagware after that point...)

PlugData: You GOTTA TRY THIS, it's not mentally for everyone (not HARD exactly, just WEIRD) but if your brain works well with this kind of flow graph stuff it's a magical playground of music. (If you have heard of PureData, PlugData is based on it but has a lot of nice graphical upgrades and can work as a VST if you have a proper DAW)

Surge XT: A big ol' synthesizer plugin that also can run standalone and take midi input so you can technically use it to make music even if you don't have a DAW. If planning notes ahead of time sounds intimidating, but you can get your hands on a midi piano controller, this might actually be a great way to start out playing with music on your computer!

Bespoke Synth: Another open source DAW, but this one is... sort of exploded? Like PlugData you patch things together with cables but it has a wild electrified aesthetic and it can do piano rolls. Fun though!

GAME DEV:

Yeah that's right, game dev. You ABSOLUTELY can make video games with no experience or ability to code. I actually recommend video games as a way to learn how to code because the dopamine hits from making a character bumble around on a screen are enormously bigger than like. Calculating pi or something boring like that. ANYWAY:

Twine: Twine is what I might describe as sort of a zero-barrier game dev tool because you're literally writing a story except you can make it branch. It has programming features but you can sort of pick them up as you go. Lowest possible barrier to entry, especially if you write!

Godot: I use this engine all the time! It's got great tutorials all over the internet and is 100% FREE AND ALWAYS WILL BE. Technically there are more Unity tutorials out there, but Godot has plenty enough to learn how to do things. It's also SUPER LIGHTWEIGHT so you won't spend your precious hobby time waiting for the engine to load. There are absolutely successful games made with this but I think the best thing about it is that the shallow end of the learning curve is PRETTY OK ACTUALLY.

#art #hobbies #free software

7 notes · View notes

dreammelter · 2 years ago

Text

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.)

#long post #game dev #yee.txt #if there are typos and stuff pls forgive meeeee #i'm dropping this here so i can go finish chores and stuff ;;;;

2 notes · View notes

hullbreachgame · 2 years ago

Text

First Update!

Hello! I'm Duncan, and this is where I'm going to be posting updates for my personal, hopefully-to-be-completed-one-day game project!

The quick sales pitch: Heat Signature with a dash of Hardspace: Shipbreaker.

The less-quick sales pitch: A game where you play a highly disposable (and incredibly indebted) fixer who solves a big problem that a lot of individuals and companies have in the time of FTL travel; sometimes you would very much like something, but unfortunately it is on someone else's ship. In fact, it is often not just on someone else's ship, but in fact behind large amounts of personnel who may hold some strong objections to removing it from their ship. Or, they may in fact be the asset that needs retrieving and may not be particularly interested in coming quietly. Your goal? Completing the objectives set forth in your contract, employing whichever methods suit your particular tastes as well as the contract's stipulations-- some might want you to use a more delicate touch, while others want to send a message. Do what you can to earn as much as you can and maybe even pay off your debt-- or just try and enjoy the relative impunity you operate under.

Things are very much in the planning and testing phase right now. So, without further ado, let's get into one of the big things being worked on right now: Destruction.

------------------------CLANG - what was that?!-------------------------

The game is being developed in Godot 4, which is a fantastic engine for people who are a bit less experienced in the development space. It does have a few major downsides though, and one of the huge ones is a lack of assets and libraries. This makes it a little bit harder to get things moving and also means that there is the need to kind of develop quite a few things completely from scratch.

One thing that people who have messed with things like Godot and Unity in the past would probably understand is that you really want your collision objects to be convex. Basically, nice and solid, no holes or dips. You can stick a line in anywhere and it will only ever exit in one spot. In fact, you cannot even have rigidbodies with concave collisions in Godot. This is because it's really hard to calculate concave collisions, and really expensive on a computational level. This translates to: please have mercy on my framerate.

This generally isn't a huge problem, and there's plenty of ways to get around this, like just using static bodies, manipulating collision masks (which I actually will be using for a few neat things!), or you make sure that your concave objects, like a tunnel, or a doorway, are composed of convex polygons. A square room, for example, isn't just one big cube typically, it's six squares representing each face, 6 distinct collision objects.

It might be useful, then, to have some ways to break a concave shape into convex ones. And you'd be right! In fact, you'd be so right, that you'd assume it was a problem we've completely solved. And you would not be correct unfortunately! It's a topic that has a truly gargantuan amount of research poured into it. Google "Convex Decomposition" if you want to learn more about the subject-- it is genuinely very interesting-- there are people far more qualified than me to talk about it.

I have some plans in mind to solve the problem in a way that is performant for my needs, and I will also be (hopefully, providing it doesn't end up being utterly impractical) releasing these tools on their own within Godot so that other people can use them for free as well!

Actually writing out the code for it is... interesting, to say the least, as I am not gifted in the ways of geometry, and did not know too much about mesh generation until recently. However, I am currently working at implementing a very quick-and-dirty 'hole cutting' method right now.

Here is a gif that shows off the basic process for how it works:

Here's an explanation of how the general process will work:

Figure out your hole shape-- in this case, it's a square hole made by the rod punching through the prism. Get the points along the corners as well as your direction. In this case, we've got the 4 points on the face closest to the camera and pointed towards the left face.

Make a plane that is flush with the first 2 points and in the direction of the cut. Everything to one side gets snipped off of the first mesh and moved into another one (we don't actually separate them, but it is separated for easier visualization). Additionally, make a note of the first point in the hole and its intersection point-- in this case, bottom left point of the hole and about 3/4 of the way along the bottom of the prism.

Now-- repeat this step until you get to the last point of the hole; create a plane flush with the side, snip off everything on one side, and move to the next side. Connect everything up. Additionally, if this is the last repeat of this step, make a note of if you have intersected the two points from step 2. If so, you can drop the intersection point from step 2.

For the last points, just connect the previous point, the first point, and the intersection point from the previous point and the first intersection if it wasn't dropped.

After you've gotten all those pieces, you can just replace the original mesh with the 4 new ones. Tada! You have what looks like a hole through a mesh, but in reality it's 4 segments. If you're so inclined, you can also make the surface of the cut its own material-- maybe you want the 'inside' of a wall to look different.

Now, this solution isn't perfect. It cannot be multi-threaded in this fashion, since the sequential cuts depend on the prior cut to happen. I have a few other methods that could actually be done simultaneously, but this one is pretty easy to visualize and for the purposes of the game it should be completely functional. The astute among you may also realize that this will not work for concave holes without a few changes-- this is actually not the hardest fix, but it won't be relevant for the purposes of this type of destruction. It might be included in the library, though!

My next goal is to actually get this method implemented in Godot so that I can show it in action! This will also get me a bit more comfortable with mesh manipulation.

After that, we will be able to get to some really exciting stuff as well with some more... dynamic destruction. Cutting holes is all fine and dandy, but what about smashing them? Hopefully you'll see some more on that in the future!

#godot #godot engine #video games #gamedev #blender #space

4 notes · View notes

kikiparagame · 4 months ago

Text

First Entry - Game Engines: Unity vs. Godot

Dear Diary,

Hello! ( ⸝⸝•ᴗ•⸝⸝ )੭⁾⁾ If you came from my Instagram, welcome to the longer version of my diary entry. If we met through here, welcome! (hi!)

Welcome to the BTS of KiKiPara:) I wanted to share the BTS of the beginnings of the game and be open to the process of its making! I’ve got inspiration posts planned as well as NPC character intros, but the very first thing I want to tackle/talk about is…

dun

Dun

DUN

✧˖°.GAME ENGINES✧˖°.

Y��all, who knew you could have a life crisis over a game engine? I was so close to crying(?? unfortunately (╥﹏╥)) and looking up SO MANY REDDIT POSTS ദ്ദി ༎ຶ‿༎ຶ ). I genuinely was having such a hard time. I heard that Unity was a great beginner engine, but Godot is incredible and should be considered in the ranks as a solid contender for game developers.

And YALL OH

WORD

╰（‵□′）╯

I couldn’t choose!

So what did this little missy decide to do?

*sarcastic cheers*

Play with both engines feelings like a situationship!

(ᵕ—ᴗ—)

For realsies though, let me explain. Unity has been well known on the market for years but, as an indie developer, ngl, the fees scare the heck out of meee:( But that's a problem for FUUUUUTURE me.

٩( ᐛ )و

Outside of the fees, learning C# has been a really fun and challenging coding language and Unity the engine--- (I WANT TO UGHGHGHGHGHGH--- ╰（‵□′）╯)

Having a cool setup and learning C# in Visual Studio made me feel like a real programmer and-

*screams into oblivion because it took seven HUNDRED THOUSAND YEARS FOR ME TO LOAD A TUTORIAL GAME*

(ᗒᗣᗕ)՞

yaaalllll my SOUL.

Doing Game Makers Toolkit (GMTK)’s Flappy Bird-esque tutorial, this gal was STRUGGLING, but she got through it and it was frustratingly rewarding enough that she proclaimed to the stars ⋆｡°✩ that this would not stop her from accomplishing her dreams.

Now Godot’s tutorial by Heartbeast? So much fun. Learning Godot was a genuine dopamine rush. That engine was fast, scripting was in-engine so you didn’t need to travel beyond one computer screen, and seeing your results as a tangible game was readily available within SECONDS—OHMYGOODNESS ദ്ദി(ᵔᗜᵔ) Godot is genuinely incredible. But… The thing is… It felt too easy if that makes sense? Like I wanted a challenge and it felt too… comprehensible? I may be going absolutely crazy by saying that.

So with everything that's been going on, for the moment, I've decided to go with _____________!

Genuinely I still haven't decided! And that's okay:) I'm working in Unity in the moment, but who knows ¯\_(ツ)_/¯ maybe Godot will steal my heart ˚ʚ♡ɞ˚

So that's what we've been working with, Diary. It's been a long two weeks just to (not) decide on a game engine and I'm ready to jump in!

Well, I'll see you later, Diary:) I'll write soon.

⊹₊ ˚‧︵‿₊୨୧₊‿︵‧ ˚ ₊⊹

Mrs. B

#game #gamedev #game developers #fashion #fashion game #style savvy #fashion dreamer #inclusivity #game development #dev log

0 notes

rindevlog · 9 months ago

Text

HALLO I FORGOT TO MAKE A DEVLOG YESTERDAY (not really, its more like I just didn't do any dev work yesterday O_o). However! I bring good news... I THINK IM HIRED!!! "I think" because the recruiter that hired me said that the manager is gonna email me stuff but I havent gotten it yet so idk if he jus pranked me saying congratulations O_O"" HOPING FOR THE BEST THO! Another good news is that I have optimized the dialogue system a very tiny bit, and have updated the inventory system so it works perfectly! It's very simple tho so I don't see it being used in other, more complicated projects. But it's a good start, that's for sure!

Yesterday, a small reason why I didn't get to do some dev work is mainly bc I'm a little sick, my throat is like covered in thick ahh phlegm that's so annoying to deal with. It wasn't that bad, like I could still function properly but idk, I just didn't feel like coding. BUT! The main reason why I didn't do anything for devving is because I drew a lot! not really a lot, I did like 3 sketches and suffered for hours about developing the lineart... I think I'm just gonna stick to winging it and adding lineart at the end... I'm drawing Bocchi from Bocchi the Rock! :3

Today, Sept. 26, 2024, I found a new tutorial to guide me for the inventory. I thought my method of just having like a boolean system like if have carrot == true, type shi was simple enough, but it just brought so many complications. Now, I'm using an array of item resources, and the same inventory is the same with everyone, so it's going to be like, if they give you this, they lose it in their inventory. Not really important but it kinda helps I think? It just makes sense, I'd say, considering I'm planning to implement a system that features that very basic thing. I made NPC resources as well, containing their name and sprite for now. I think it also contains their root dialogue?

Like I said earlier, I want to optimize the dialogue because if I keep on with it, the game might end up too big. Instead, I'm considering having chains of lines of dialogue. I'm also thinking of adding their questline in their resource file but I need to first figure out how I want the quest to flow. But, I'm not sure if I'll be able to implement those tomorrow since I'm gonna be going outside with my girl. We ARE gonna be doing some work together (she's studying) but I wanna focus on developing concept art for the game jam I'm in. It ends November 14th so I think I still have some time? I am considering making it on RPGMaker first though since they have all the code already and I just have to edit them; it's gonna be quicker there, basically.

After Knowlerdge, I'm gonna put my full attention to the concepts for the game, Prey for the Devil (TBD). Once I'm done with that, I'll start with the RPGMaker project, and then a little bit on learning more godot. Damn, this has been a huge yapping session, I'm sorry for the massive walls of text... As always, thanks for hearing me out! I hope the manager calls me soon because I obviously don't wanna stick to false hope. See you in the next one!

0 notes

canmom · 2 years ago

Text

Natalie Lawhead does good as ever, this is one of the biggest collections of game engines I've seen anyone put together.

It's worth discussing what's missing from a lot of these engines - the features that kept people with Unity instead of these alternatives. Not to say we have to stay with Unity, but the big challenges that other engines have to meet.

The biggest one is multiplatform support. Particularly if you want to release games on consoles (Android excepted), you have to deal with all sorts of opaque black-box proprietary APIs and all sorts of weird gotchas and headaches. One of the best features of Unity is that it runs, and runs well, on nearly anything. Which isn't to say Unity doesn't have its own gotchas trying to build for different platforms, but it provides a very good abstraction over a lot of difficulty.

Unfortunately, console support is a big barrier for a lot of open-source projects. Godot spells it out pretty clearly. The console manufacturers won't license their proprietary devkits to an open source project.

This means the only real alternative for console dev is Unreal, or a proprietary engine. Unreal isn't quite as universal as Unity, but it's fairly close. It handily beats Unity on high-end graphics features. However, its design is generally less flexible, and the editor is quite cumbersome and demands a pretty high-end PC. It also doesn't have the CPU performance of Unity DOTS, even though it's written in pure C++.

(For standalone VR, Unity has been pretty much the only game in town, but the situation isn't as dire as other consoles since Android is at least open source and OpenXR provides an open source abstraction layer that other engines can implement. So while there's not a great Unity alternative yet, it's entirely possible that Bevy or something else could become viable.)

That leads in to the second reason - performance. I've been watching people in the Latios Framework discord try and figure out some alternative ECS-based engine for the kind of super-high-performance code that Unity DOTS enables. Unity DOTS is kind of an engineering miracle. The Burst compiler is fantastic - only the Rust compiler can stand alongside it really (not surprising since both are based on LLVM) - and there are a lot of extremely smart design choices in how it handles e.g. ECS iteration and rendering.

There are other ECS-based game engines out there, with Bevy probably the most advanced. It's also possible to cobble together your own by combining an existing engine with an existing ECS library. The problem is that for a realistic game engine that goes beyond a tech demo, there are a lot of pitfalls that can erode the benefits of ECS (a somewhat polemic article, but a good explanation of how ECS alone doesn't guarantee great cache performance). Bevy currently doesn't have the rendering performance of Entities Graphics, although it's moving in an exciting way.

Unity is a strange beast - it's a hodgepodge of features, some of them really cutting edge, some of them more or less abandoned after the people championing it left the company. There are usually multiple ways to do any given thing (e.g. user input or UI), and it's a bit of a steep learning curve to go from 'using Unity' to 'using Unity well'. However, the good parts of Unity are actually really good. It's taken years to get them this good. It sucks to have to reinvent it.

(The third reason is of course there's a huge amount of expertise and assets and shit built up around Unity. But - unless Unity does some pretty drastic actions to regain trust, or it dies and gets opensourced - that can't be helped, the ship's going down, not now but likely in a year or two when the currently-in-progress Unity projects have been released.)

It's probably going to be pretty chaotic for a while. What I really hope is that when all the dust settles, the 'next Unity' will be free software that can thrive as much as Blender has without risking this kind of 'enshittification'. With both this and Flash, it's fucking appalling that such a huge block of cultural output could be put at risk of being erased by the actions of one company. Also it will be the year of Linux on the desktop and federated social media you guys. For real! I promise!

A great look at what Unity alternatives there are out there besides running from one for-profit corporate product to the next

#computer games #game development #unity

304 notes · View notes

iskotaa · 3 years ago

Text

Devlog #1: Godot Warrior

The free "Learn to Code" game I'm working on, Godot Warrior, continues to progress quickly! The game runs on a player-coded script, which you use to control your unit, like the example below:

This ends up being a bit of an "endless" runner where, if your script is written well, you should be able to make it through each level in one go. Abilities are locked, though, so you will have to stop and adjust your script throughout.

I'm getting most of the UI done and I'm excited to to release this within the next couple of months (if I'm lucky). As with all development, though, I feel like I find about 4 new bugs for every feature, but it isn't slowing progress too much.

That's all for now!

#godot engine #made with godot #learn game dev #game development #gamedev #indie dev #learn programming

10 notes · View notes

perfectlovevn · 9 months ago

Note

After completing the perfect love extras, what is the concept of your next game if you already have one?

This game was actually the game I was working on before I started on Perfect Love. Alpha's Day Off is completely different in tone to Perfect Love in that it's much more light hearted. It follows a girl named Alpha who is hanging out with one of her four friends. The idea is basically to showcase these characters and their interactions as well as the general lore of this story. I've had these OCs for a while so I really wanted to be able to showcase them. For those wondering, this is the world where Valli comes from.

I originally was coding this one in renpy where I was able to learn the basics, and I actually have about half the script done. But then I got too big brained and decided that I'm going to try to make this game in Godot instead. Horrible idea, I know considering I've never used Godot in my life. I kept getting hauntings of trying to learn how to make mini games (though hopefully ones that aren't extremely complicated) so we will see how long it takes me to get anything done. If this game takes too long, I may just decide to make a game with the people from First Impression (the world from Desmond's game).

Anyways, I hope we can see how it goes!

#perfectlovevn #yandere vn #perfect love vn #yanderevn #milo asks #about alpha #about valli

32 notes · View notes

andmaybegayer · 5 years ago

Note

Hello, I'm a fool who knows nothing about computers with a couple questions. For reference, I'm on Windows, for no reason other than I prefer it. I want to make a video game, a very very large video game. I'd be making it out of the love of my heart and for people to play, and not for any other reason. It would be a third-person 3D game. Now, I've heard that RollerCoaster Tycoon 1 was built in Assembly, and is thusly able to run just about anywhere, though I don't know the truth of that. 1/2

Hey yeah tl;dr you should Not try and make your game in assembly, especially as a beginner. Your best bet is to learn a modern game engine and start with that. Especially nowadays if you can get your head around Unity or Godot or any other similar game engine making a 3D game is, while not ~easy~, much easier than it ever was in the past when you would have had to roll your own engine from scratch.

The guy who made Heat Signature and Gunpoint recently started a tutorial series for “Make a game in Unity with no experience.” which may interest you. From there you’ll want to learn how to design 3D objects in something like Blender or Wings3D so that you can build your world and texture it.

I’d recommend starting small, Big Game Projects are ambitious but you’ll want to put out a few small things first, something like a game where you walk around, say, A Single Building with a garden and talk to NPC’s in the building, maybe have a combat system, etc. to really get the hang of your tools before attempting a project where it won’t seem like anything works for potentially weeks of work.

I have tons of little dead-end projects that were dedicated to figuring out simple things like “How do I create randomly generated terrain” or “How do I make Gun.” There’s plenty of YouTube tutorials basically dedicated to stuff like this, Sebastian Lagues’ Coding Adventures are basically all videos dedicated to exploring how to create common interesting things in Unity that you might want to use in a game like random terrain, portals, weird gravity etc.

You’ll have to pick up A Language but it’s honestly not that hard. One thing you will want to do if you’re doing game design is brush up on your high school trigonometry because a truly ridiculous amount of the maths you will do in the process of making a game is just finding relationships between angles and coordinates in space.

Rolling your own engine is a good learning experience if you’re interested in how to write optimized code, designing a scripting language, and writing really wacky dynamic code, but if you just want to Make A Game for your friends to play then it’s a waste of time.

The long explanation for this is:

Assembly is a very powerful but extremely specific tool that’s only useful in the modern day in a very specific handful of situations.

The lowest level of programming that you can do (more or less there are some lower levels that don’t count) is Machine Code programming, which is where you write the binary instructions to a program out by hand. This can be done and is indeed how we used to do it in Ye Olden Times but even in Ye Olden Times programmers quickly got bored of this and invented Assembly.

Assembly is a very simple mapping from raw binary code to a somewhat human readable system. Talking about what that binary code looks like without a firm grounding in processor basics is hard but needless to say that binary generally represents something like Operation, Data1, Data2, Data3, for example you might have a set of codes that correspond to Add A, B, C where that adds A to B and stores it in the address at location C. That instruction in binary will be like 0110 0001 0010 1001, but that’s a pain in the dick to write so you write a simple program that can read in you writing “ADD A B C” and convert it to the right binary code.

In contrast to more high level languages, the mapping between assembly and machine code is pretty direct, usually 1 to 1 or almost 1 to 1. You can’t really do an “if X is true then do A” in assembly, instead you have to do “Compare X to True, check if the True flag was set, if so then jump to the location in memory containing A.”

This has some advantages, like, if you’re very familiar with the processor you’re using and where you’re storing everything in memory, you can skip certain steps you know you don’t need and dramatically speed up your software. Old games, especially for games consoles like the GameBoy and PlayStation, would be partially or wholly written in Assembly so that they ran fast on very limited hardware (the original PlayStation had a stunning 2MB of system RAM) . There’s lots of programming libraries for doing extremely fast maths written partially in Assembly for this very reason.

The DISADVANTAGE is that you have to be really good to write faster code than a quality optimizing compiler. Even fairly barebones languages like C have a lot of creature comforts that make programming nicer, faster and more readable, such as having language constructs to create loops, systems to help you create structures in memory, etc., and once you put that code through a modern compiler it will add in its own very smart optimizations that can make even fairly amateurish code run extremely quickly.

in Assembly you have to do all of that by hand, and doing so requires tracking a lot of things manually. It’s not something for the faint of heart and building a modern game entirely in assembly is something you wouldn’t really do if you could avoid it.

That’s not to say it can’t be done. Since ultimately all programs boil down to machine code, there’s nothing stopping you from making a full 3D game in assembly. Rollercoaster Tycoon is almost all assembly, as you said. Indeed plenty of old 3D games are written partially or mostly in assembly for performance reasons, and if you use a game engine like Unity, some chunks of the engine will be written in Assembly for speed. Especially when it comes to things like realtime physics or very fast AI and the like.

On modern computers for even fairly complex games, the performance of well-optimized compiled code in a normal language is plenty for most games. The benefit of using Unity is that you can leave the heavily optimized engine stuff to a team of skilled programmers who’ve been writing game engines for years and you can deal with the unique things that you need to make your game happen. If you were to start writing a game in Assembly you’d first have to design your own engine, probably write your own scripting system, etc. which would require a robust basis in programming language design, parser design, and a firm view of what you want to create. Tooling around in Unity experimenting with things as you go is much easier.

Learning Assembly and getting good at it is a valuable skill if you want to write crazy optimal code and get a robust understanding of how the internals of a computer work (although not actually but I’m not going to talk more about microcode beyond linking this video lecture) and fi all you want to do is make Video Game your best bet is to learn Unity because it’s what everyone is using.

Pitches for other engines I like but that might not be for everyone:

Godot: Basically a fully open source baby unity that is a little easier to use but a lot less powerful and with a much smaller community, I really like it for experimenting

LÖVE2D: Not a 3D engine, but a really minimal 2D game engine that uses Lua for scripting. It is extremely bare bones but gives you a lot of room to program all behaviours yourself if you feel like making extremely fast demos, I mostly use it to write graphical simulations.

LÖVR: A 3D game engine heavily inspired by LÖVE with a focus on VR game design, shares the same bare-bones, lua-scripted design that makes it very suitable for quickly throwing demos and experiments together but less suitable for large projects unless you pull in some libraries.

#computer stuff #programming #game design #video games #ask #theyhylianbatman #software

10 notes · View notes

phonoforest · 5 years ago

Text

Top-Down RPG Game Design Tools and Resources

A lot of developers are starting out creating simple top-down rpgs as their first games. This genre can be a good choice for a first game for a few reasons. For one it's a very popular format so there are countless resources available to help you on your journey. Another reason is they are fairly straight forward to design and don't require a lot of technical ability to make. If you are new to art, pixel-art isn't too hard to get into, if you're new to programming there are many tools, libraries and game engines with built-in tools, a lot of which don't require you to code at all. And the last reason is related to design; it's easy to envision what your game will look like when it's done before you even get started because the genre is so classic all the design problems have already been solved for you in games from decades ago. So without further ado here is a list of all the tools and resources I could find to help out someone who's just starting out developing a top-down rpg game.

Game Engines

Godot

Godot Is my favorite Game engine by far so my opinion will be biased here. It's great for beginners there's plenty of tutorials available, and it's completely free and open-source so you don't have to worry about some company taking a piece of your profits. Right now it's lacking in some 3d features but since this article is about retro rpg style games that shouldn't matter too much.

Rpg Maker

RPG maker is great for beginners because you don't have to code, there's lots of free art and sound assets build in and it's designed specifically for making, you guessed it, top-down RPGs. There are a few downsides however. It's not free, the cheapest version as of writing is $25, so not too bad. Another problem is how restricted you are in the types of games you can make. If you want to make anything other than the cookie-cutter RPG-Maker style game you are going to run into problems.

Unity

Unity is a great all-purpose game engine. It's one of the most widely used by far, so the amount of tutorials are endless, so finding a specific tutorial for almost exactly what your trying to accomplish is very likely. The downsides aren't too bad either. The first one being that once your company makes over $100k annually you have to buy a monthly subscription for unity pro for $150/month. The other is that unity was designed as a 3d engine first so 2d features sometimes take a back-seat, this can sometimes lead to frustrating bugs where your 2d objects get lost somewhere in 3d space, but this is really just a nit-pick and can easily be fixed. So overall Unity is a very solid choice.

GameMakerStudio

GameMakerStudio is A great game engine targeted specifically at beginners who are a little afraid of code. It has a powerful drag-and-drop visual scripting language that a lot of people really seem to like. It's a really popular choice for 2d games. It's not free though and buying all the add-ons to build your game for different platforms can get really pricey.

Art and Design

Aseprite

Aseprite is probably the most popular pixel editor recently. It costs under $15 dollars and the price is well worth it in my opinion. There are lots of youtube tutorials to help you learn it's many features. There's not much else to say, it's a great choice.

Krita

Krita is free and open source. It's a general use digital art program so you have to do some set up to get a good pixel art workflow going but it has all the features you'll need and more.

Tiled

Tiled has been the most used 2d map editor for a long time. It's free and open source. It may not be very intuitive to use but once you get the hang of it you can get some serious efficiency out of it. And once you make a map in Tiled you can easily export it to basically any of the popular games engines on the market.

OpenGameArt

This one isn't so much a tool as it is a resource. OpenGameArt is a site where you gen get royalty free game assets to use in your game. If you aren't very good at making art and have no budget this is probably your best bet.

http://www.phonoforest.com/2020/02/top-down-rpg-game-design-tools-and.html

#gamedev #indiegame #pixelart #retro #rpg

1 note · View note

eclectia · 6 years ago

Text

Dev-It-Yourself: A Place to Start

I'm a hobbyist games developer not professionally taught in any capacity beyond A-Levels, and one of the biggest hurdles to me actually getting stuck in was feeling as though I didn't “know” enough. I felt, as many do, that I had to be an expert at coding, art, animation and so forth. This was, until I realised, there are actually plenty of resources, tutorials, books, YouTube videos, blogs, and much more besides all dedicated to discussing games, the culture around games, design and development processes and much more besides. I firmly believe that restricting yourself to learning exclusively about video games and nothing else, no other media -be it print or film-, is restrictive and reductive to both the medium and yourself. Plenty of hobbyist/independent developers, such as myself, have used these sources to aid our learning, and frankly, I don't see there being any shame in it in any capacity. If the information is out there, use it. Create with abandon.

Of course, in my other series I talk about how playing games can help too but it is much more than just “playing” games, in the same way I was taught way back when to always be 'reading' [ie, analysing] films as I watched them. As always, I'd say take this advice with a pinch of salt- I'm no professional, I do this in my spare time at an average-ish level. But, this is just a collection of personal resources that have helped me. Later on in the series, I'll be laying out how I've planned, conceptualised, designed and made games I've worked on in all stages. Again, purely anecdotal – I'm no expert.

One of the first places I'd suggest any prospective dev would look to for practice and inspiration would be the modding community. There are plenty of games out there which provide modding tools with them, and these can be a good place to go and practice level design, gameplay concepts, and just messing with basic code structures. GMOD, Half Life, Bethesda Games, even DOOM wads can be great places to begin; you can get a feel for yourself for things that work, how to fit things together organically, even using full conversion mods to take asset creation out of the equation to focus upon writing for a small time. This is where I started, though none of those mods came out, it became a great place for me to practice and eventually, grow confident with concepts.

In a similar vein, there are a few software packages that come with assets and engines inbuilt that can be great ways to practice and develop skills such as level design, writing, and so on; software such as RPG Maker, which comes in all sorts of modules, can be surprisingly versatile. You can use it to make levels from assets known as RTP that come with the engine, use assets provided by the community, or modify pre-existing assets for your own needs. Again, this is something I practiced with a lot as its modular coding system -which comprised of a lot of drag-and-drop and clickables- helped me familiarise myself with logic systems popular within coding, as well as how to design levels to look and “feel” good. And, once you've gotten familiar with the basics you can familiarise yourself with basic tileset rules, layers, and interfaces – and, with a bit of creativity, these can become unique ways to make games. I've seen scanned-in images, photographs, hand-drawn assets all utilised with RPG Maker to make something wholly unique. Check out Middens and Mortis Ghost's OFF for two examples of unique, stylised art created with RPG Maker in two completely different styles.

For practicing code at a base level, a basic grasp of HTML is often a great place to start. Software like Twine enables you practice both story-telling,and basic code from hyperlinks and hypertext to more complex code such as branching choices or choose-your-own style adventures. You can even incorporate text, audio and macros which, again, is a higher level of code, though by no means as difficult as it can be, it can be really useful for practicing basics of these skill-sets.

The reason I suggest most of these as good starting bases is one primary reason: asset creation takes a long time. Making your first project might well be forefront in your mind but I've learned, mostly through trial and error – and a lot of error at that – is that you need to focus on specifics when teaching or learning. If you try to learn coding, asset creation, animation, all at the same time it is possible but often not manageable, or at least not in my experience. By saying to myself “I'm going to focus on HTML”, it has allowed me to properly learn and understand the fundamentals without getting distracted by art direction too. All of the software I have recommended comes with in-built assets or at its core requires no asset use at all and this is useful for zeroing in on what you need to focus upon. Maybe you're already good at level design, and through experimentation you realise this and decide to focus upon animation or character deisgn.

And, when you want to take that next step these programs also have, either through the ability to edit or bring in your own assets, ways to practice and hone your other skills in relatively streamlined ways. RPG Maker tileset functionality was important for me to learn two things: multi-frame animations, and how to correctly place tilesets. Neither is particularly complex, but if you get one bit wrong in a tileset it can throw the whole asset off, and whittling down the animations to four key frames, to communicate the essentials, was a useful skill to learn even as I expanded to larger animations.

Another piece of software that I have found invaluable was PICO-8, a virtual console that you build and execute games with and, the slightly more complex but still ultimately easy for beginners Voxatron, from the same people. Everything in that is inbuilt so you build your assets and code within the engine, then the virtual console does the rest. It allows for easy exportation and initial conceptualisation – I've heard that the first build of Celeste was built in it.

Once I felt as though RPG Maker had taught me all it could, I moved on to looking for open-source games engines for more complex experimentation. I've dabbled with Unity, Godot, and a few others besides that. I use Game Maker a lot these days, just because it agrees with me the best. What works for me and what works for you will probably be entirely different, so don't take my word for it- look into documentation, experiment with the engines mentioned yourself, find what works for you. And remember, most importantly; everyone starts somewhere, don't give up because your first idea/s don't come together as you anticipated, or end up “rubbish”. Keep going, keep creating.

#indie dev #game development #indie games dev

5 notes · View notes

ludosgd · 6 years ago

Text

Designing Solitude — GMTK Jam 2019

Hiya! LudosGD here!

Recently, I participated in the 2019 Game Maker’s Toolkit Game Jam. For this jam, I made a game in just 48 hours. This game is called Solitude and you can play it here!

Since I love talking about my projects, I feel like this is a good occasion to talk about my experience in this jam! So grab a cup of tea (I prefer hot chocolate but you do you, I guess) and follow me in this 48-hours-long journey.

BEFORE THE JAM

Ok, maybe we’ll start a bit earlier than the jam’s beginning. When the GMTK Youtube channel announced the jam, I was so hyped. I was already getting started with the Godot Engine and was only looking for an excuse to make a game. This jam was the perfect opportunity.

During the months between the announcement and the jam, I participated in another jam: My First Game Jam! ( @myfirstgamejam )

It was a really cool experience: it made me much more confident about my abilities, the community was wholesome, kind and engaging and I had a blast participating in it. It’s worth noting that My First Game Jam was my actual first game jam. My first ever published game is my submission for it: it’s called First Few Blocks and you can play it here!

Now, back to the GMTK Jam. Compared to the chill and welcoming atmosphere of My First Game Jam, the GMTK Jam was intimidating. Like, a lot.

Sometimes I asked myself if participating was a good idea. To give perspective: I made a single platformer level in two whole weeks for My First Game Jam. How could I do something in just 48 hours? In the end, I convinced myself that I had nothing to lose and it would be a waste of a fantastic opportunity.

It went well.

Like, very well.

C’MON AND SLAM, AND WELCOME TO THE JAM!

The theme of the jam gets revealed and I’m already banging my head on the desk to get an idea that fits the “only one” theme. You see, I didn’t want to make a normal game who deals with the theme only partially: I wanted it to be central to my design.

After a good talk with my sister, the idea struck me like a lightning: I asked a really stupid question. “What if it’s a game where there’s only one thing on the screen?” It sounded stupid enough to work. I decided to go to sleep and work on it the next morning.

The next morning, I made the point of the situation.

I needed good sleep, pauses and hydration. If I wanted to make it alive through this, I knew I needed to treat myself well. Nearly everyone is more productive (and happier) if well-rested and healthy.

I didn’t have much time to work with. I knew from the start I would have had simple graphic and a simple design. I wanted a cool little game rather than a big, unfinished and clunky one.

“Only one”.

Ok, so, how do you do a game where there’s only one thing? Rather than having only one thing, I thought it would be cool having only one visible thing. I coded a prototype of a simple top-down game, and then added the main mechanic of the game: the player can scan the level with WASD to reveal things around them. To maintain the theme, I made it so that every time the player scans their surroundings, their sprite becomes invisible (so that only one thing is invisible).

This made the gameplay a lot more interesting: you have to plan each of your movements and be very careful. You can’t really plan ahead in this game, but each and every movement must be thought out. You can’t just “go ahead” without thinking. This slowed down the pacing of the game but didn’t make it less enjoyable: it is instead more intense than your average top-down game, and its gameplay kept the player on their toes.

To reinforce this “I don’t know what’s next” feeling evoked by the gameplay, I used sound effects, music and, to a certain extent, graphics to give the game an unsettling atmosphere.

The main mechanic of the game (you can only see one thing at a time) makes the game much more difficult than a normal one; so the levels were adjusted accordingly.

The first level introduces the player to the world, to the mechanic and teaches them what an enemy looks like. I made it very easy to not scare the player (it’s easy for them to just change game). I want to hook the player and let them beat at least one level.

The second level is more challenging and feels like it's the first "real" level.

The third level introduces you to a new mechanic: the key.

The level structure is different too: instead of being a fixed path, here there are four "rooms", so the player has to explore the area once they find out the door is locked.

The fourth level is where the difficulty raises a lot (too much if you ask me). This should have been the fifth level; once I realized I wouldn’t have been able to make five levels, I decided to take a risk and sacrifice the “real” fourth level, because I wanted something spicy for the hardcore players!

As for the graphics, I chose a minimalistic artstyle for many reasons:

I’m just beginning with pixel art;

I needed to make the sprites in a timely manner, since I had only 2 days to do the whole thing!

Since the game isn’t really about the looks (is it about “non-looks?”), I thought that a minimalistic approach was enough.

After tinkering with the music and sound effects (I used Audacity to adjust the audio), the game was finished! I uploaded it on itch.io, added the key-holding sprites of the player (this way the player always knows when do they have the key) and re-uploaded the game, just in time to be involved in the whole “itch crashed because the jam is too big” thing. Both the itch team and the GMTK team handled this well but man I was scared. All went well in the end though!

THE FEEDBACK

I got a lot of positive feedback! The game did really well and received a lot of comments saying how much they liked the game. Many offered constructive criticism too! I’m still stoked by how many people liked my lil’ project. Thank you!

And then, on August 12, the impossible happened…

Solitude got ranked 74th! I couldn’t believe it. For starters, being in the top 100 means that Mark Brown, host of Game Maker’s Toolkit, gets to see and play your game! (Do you feel the “senpai noticed” vibes?)

I’m really grateful for all the positive feedback I’m receiving.

Thank you all.

I don’t feel intimidated anymore.

THE STATS

So, to conclude this absurdly long post, I’m gonna list some of the things I learned from this experience, both from the hits and the misses.

Because of this jam, I used Godot, Audacity and Photoshop. I used programs for screenshots and gifs too. Not to talk about using itch.io. I used a lot of things in just two days. Honed my skills on a lot of programs!

I learnt how to use raycasts in Godot! I think coding-wise this was the biggest challenge for me.

I met a lot of awesome peeps ( @doujindev I’m looking at you ) and got a bit more in touch with the gamedev community!

I missed many little details, like showing the enemy for a brief moment when it touches the player; this way the player knows what killed them. This was suggested to me by Game Endeavor (check out his Godot tutorials)! I think it’s a fairly important detail because the player shouldn’t feel “cheated”, and this little feature can prevent this feels-bad moment.

The last level is simply too much, it requires the player to pass a three vertical-moving-enemies column, two times! It would’ve been a fair level if it was the 10th level, not the 4th...

Spamming WASD seems to be a strategy many use, but it generates eye-hurting flashes. It’s another little detail that I consider pretty important.

I had a good workflow, even if I passed the majority of my time in front of the screen; probably I need more pauses. You can understand me though: it was just TWO days!

I think that sooner or later I’ll add all these details and correct the mistakes in a future update of the game.

VERDICT:

This was an awesome experience and I’m pretty happy with how it turned out. I’m happy with how I tackled the various challenges too!

What can we learn from this? Don’t be scared of opportunities. It would have been an awful mistake not to participate in this.

Thanks for reading! Do you have any questions regarding Solitude or my experience in the GMTKJam? Ask me here on Tumblr or simply tag me on Twitter (I’m @LudosGD)!

Have a magical day!

- LudosGD

#indiedev #gamedev #GodotEngine #GMTKJam #GameMaker #GMTK #indiegame #indiegames

2 notes · View notes