/agdg/ - Amateur Game Development General

Just Like Make Game

(You probably don't need to) SAVE THIS FILE (any more): Anon.cafe Fallback File v1.1 (updated 2021-12-13)

Anon.cafe will shut down as of 00:00 UTC on 15 March 2024. Announcement here.

Max message length: 20000

Drag files to upload or
click here to select them

Maximum 5 files / Maximum size: 20.00 MB

no cookies?
Board Rules

(used to delete files and postings)

Open file (3.20 KB 920x512 raylib.png)
Open file (126.94 KB 800x600 losdiabolol2.jpg)
Open file (117.51 KB 1000x750 sd2.jpg)
Open file (97.06 KB 768x576 ff12.jpeg)
ARPG project with Raylib yesdev 03/30/2023 (Thu) 03:39:45 No.486 [Reply] [Last]
Greetings and salutations, faggots. I'm currently working on a 2D, isometric-perspective action RPG. The goal is a Diablo-like, minus the Skinner-box loot pinata bullshit and adding a party system with simple but configurable AI party members - think Seiken Densetsu 2, 3 and Final Fantasy XII. I'm using C++ with Raylib as my primary graphics/input/output library, no "game engine" to speak of as yet. As I'm going through a bit of a refactor, I thought I would re-organize the project from scratch and document it here in the form of a tutorial slash dev blog. I'd like to use it to dump progress updates and code snippets, as well as for it to be a place to discuss Raylib and general RPG development. If you follow along, you should be able to build a similar game without too much difficulty. Disclaimer though - I am not a pro (game developer, I do a different kind of engineering for my day job), and am new to C++, so don't expect perfect code, best design practices, or anything like that. Stay tuned for an intro to Raylib, my project/build system, and design document.
72 posts and 121 images omitted.
>>902 >lol don't kill my thread. Heh my mistake Anon. Clearly you have more to contribute, please proceed. :)
>>903 Was joke, comrade :^). And nah, I'll stop shitting up the thread. Maybe somewhere else, some other time.
>>902 >license drama (of which I am the most guilty) should be its own thread, something like "gamedev legal/ethics/financial" If we do end up with one, I am going to use it to yell about shitbirds who pretend to offer assets under Creative Commons licenses but then add restrictive "gotcha" supplemental terms that Creative Commons specifically disallow under their trademark policy. >you can have this under CC-BY (unless your game's sales exceed $X) hurr durr now we come up in CC license search results make sure you read the Free* license terms! :) IF YOU USE SUPPLEMENTAL TERMS TO IMPOSE ADDITIONAL RESTRICTIONS OF ANY KIND IT'S NOT CC-BY ANYMORE IS IT, CALL IT SOMETHING ELSE LIKE THE YOU CAN USE THIS BUT I WANT A CUT LICENSE FUCK I KEEP SEEING THIS SHIT EVERYWHERE I AM SO MAD
>>902 >GPL did not bring out the desired goal, that is, advancing 3D games and the FPS genre Well that's not so easy to measure, since the lessons developers have learned from Id's codebases aren't necessarily so explicitly stated, as a learning resource the Doom 1-3 & Quake 1-3 sources have been invaluable to many game devs. >"mod community" banging on 30 year old tech because that's all that's "free" Seems more like a problem with the culture of game development, getting the sources for 20+ year old games if the planets align shouldn't be the norm but it is. Also the things people accomplish with those very old engines are very often more experimental and innovative than what you generally get from the modern industry, you have to at least appreciate the dedication involved. >I'm pretty sure there was a Doom 2, Quake 2, Q3A... Well yeah, but Doom 1+2 and Quake 1 have the most popularity in large part due to what the community does with them, which gets spread around various places and gets people outside those communities interested in playing these new mods and total conversions. >Are you saying Id is making money off of Doom and Quake today? Yep, for Id it's a very low maintenance deal: By providing the games on Steam and other stores (generally just the original DOS versions wrapped with DOSBox) players buy the games, then take the data files and play them with source ports and mods developed completely by outside devs, Id doesn't need to get involved at all and can just let the money come in. >Presumes source port developers would keep their changes to themselves I base that on observations of other scenes where sharing your work isn't a requirement. >which is fine too, as it actually introduces diversity and competition Personally I don't think so, in those scenarios you often get certain projects having lots of control over the community, where what they say goes and people have much less power to mitigate the damage in the event of a lead dev with bad intentions. >you would have to play the original versions instead because the superior source ports didn't all release their code? That's fair, I didn't think that completely through. My concern was more about the issue of continuous maintenance when developers inevitably stop working on their port and that project is closed source, such that eventually you end up needing a jenga tower of fixes for fixes of ports as operating systems and hardware move on. >Gotta be kidding me... My point was about Id software since 2016, not during their '90s successes. The original Doom 4 was a 50 shades of brown modern shooter, which they scrapped and instead took great inspiration from Brutal Doom and the Doom community in general.

Message too long. Click here to view full text.

>>896 I did not mess with it a whole lot, mostly played through the default game, tried mods, modded a little. Demo game: worked nicely. Simple ruleset and simple resource modding (adding a new ability, etc): was indeed trivial. Variety between styles of the existing resource sets: good. From Diablo-like (Flare-game) to jRPG style (Polymorphable). https://flarerpg.org/mods/ The possible downside: Rummaging through assets of Flare-game shows that for all this fancy equipment in hands to look so nice the sprites require not only a set of standard angles, but fuckery with split layers, which does not look trivial. Not unexpected (FreedroidRPG data/graphics/tux_motion_parts/ is not for the faint of heart either, that’s just how sprite based engines do it). Probably… maybe… hopefully there’s something in documentation on how to do this efficiently.

Open file (1.25 MB 1920x1080 jam.png)
FIRST EVAR GAME JAM 6/6 to 7/7 Newt Board owner 06/06/2023 (Tue) 04:39:27 No.688 [Reply] [Last]
Hi everyone and welcome to the first /AGDG/ game jam (please clap). >what is this? This game jam is an opportunity for anons to learn and practice their programming/game dev skills in a more structured environment than just "read this programming book and then make pong or something." We (and by that I mean individually) will be making games in the "2D platformer/side-scroller" style of which I am sure you are all familiar - Mario, Sonic, Metroid, Kirby, Castlevania, Ninja Gaiden, Metal Slug, Contra, the list goes on and on. I pulled that out of my ass thought long and hard about what would be a good first jam game, the sweet spot between trivial "hello world"-like and overly complicated, and came up with platformer. In general, at the least, it's got a player character, a 2-dimensional map, obstacles/hazards, and enemies. Controlling the player character requires being able to take in and process input from either a keyboard/mouse setup or a USB gamepad and apply that to the current character state. A map, of any significant size and complexity, will require an external editor, as well as code to convert the exported map data to something your game can understand. Obstacles/hazards will need to checked for collision with the character, and the character to react appropriately upon contact (take damage, power-down/de-level, get knocked back, die, etc.). Enemies require graphics, sound, and a way to update and manage their behavior/internal state, as well as to be "cleaned up" on death or otherwise expiration (off screen, etc.). Now, this game jam is aimed at all skill and experience levels and, to try to keep people on the same page and to make things easier in general, I'm highly encouraging the use of Raylib, C++, and your choice of text editor for development. C++ is the current de-facto language for games development and in my experience, isn't as horrible as people say once you get used to it. Have to say it's grown on me this past month. Raylib is a popular games framework - not an engine - that also hits that sweet spot between extreme low-level, "to the metal" programming and "tries to be everything to everyone and fails" game engines. It respects your development freedom by staying out of the way and not hijacking your workflow, while providing all the typical low-level functionality games require - window management, input, rendering, sound, etc. >cont.
141 posts and 68 images omitted.
>>942 Great post, weird it's not getting a lot more response. Answer the man, ya faggots. >What were you trying to accomplish? My situation was a little different. I wanted to create more engagement with the board and tried to draw lurkers out and get them dev'ing. I made the little platformer with luigi and the frog enemy and shit to show people that a beginner could, in fact, make a little game in a month if they just put their mind to it, with the help of a cool library (raylib) that handles the lowest level window-creation/rendering/input handling/etc. code, while still leaving it up to you to implement all of the "game" code - state machines, collisions, character controller, level format, enemy "AI", game state handling, etc. etc. Some fag in the planning thread called me lazy like I had it done already and just rehashed it or something for the jam but the truth is my experience with both raylib and C++ were extremely limited, and work on the platformer demo started after announcing the jam - I had never done platformer development before. Another goal was, of course, to learn just like everyone else - what I ended up making was actually my most "complete" game I've made up until now. I am by no means a professional dev or anything but I do believe in leading by example. So if I'm gonna be the BO of this board, I don't want to be the faggot that says "come on you guys, just like make game..." I want to be the guy who says "Check out the cool shit I'm making. You can make cool shit too, if you just like make game." >Where did you hit or miss your objectives? We had a good turn out. For an up until recently abandoned board on the webring, we had 3 people participate (4 if you include myself) and everyone released something. That's pretty good. Where I missed though, was in thinking that total newbies would get involved. I spent a good deal of effort on making my demo code easy to grasp and modify, and was fully prepared to absolutely spoon-feed and hand-hold anyone who needed it, to change it in whatever ways they wanted to and to make it their own, or even to do their own thing using whatever engine. That no one like that showed up was a factor in me taking a more hands-off approach midway through and focusing on other projects instead. I would like for more absolute beginners to participate in the next one. It's not a competition, it's about learning, practicing, and pushing our limits. Even if you've never written a line of code or drawn a jank-ass sprite or texture in GIMP before, GTFI here. I had also wanted to improve my demo code, to replace a lot of the hacks with proper solutions. I ended up not doing that, nor did I expand the project like I had planned to: additional levels, new mechanics, new enemies, etc. I was a bit burned out with it, since I had to crunch a bit at the end to make it in time for the jam. At the same time, I made some advances with 3D in raylib that made my RPG project feasible, so I pivoted to that. If anyone was hoping for a bigger and better "Luigi's completely not endorsed by Nintendo adventures" at the end of the jam, I'm sorry for not delivering. As far as hitting objectives go, I am proud of the way that I got the release out the door on time. Defining the features I wanted and the scope, how many levels, how many enemies, etc. then managing the time to meet those goals was pretty satisfying to be honest. Not that I've never done it though, at my last job I wore many hats and basically worked alone from concept to product delivery (hardware stuff), but it's probably the first time I've committed to doing it for a "hobby" project. The scale of my current RPG project is 1000x the size though, and while I progress a little every day, having nebulous scope and time to delivery can be demoralizing at times. to be continued.
Edited last time by nviridescens on 07/12/2023 (Wed) 08:07:34.
Open file (16.91 KB 791x441 ClipboardImage.png)
>>951 >Seems strange to me. What sets the Y velocity? Is it fixed? Yep, there's a JUMP_SPEED constant that the player shape's Y velocity is set to on jump. Each frame gravity is added to give the jump its arc. By modifying the Y velocity on release (x0.5 in this case but you could go lower for snappier control or higher for less control) you give the impression of "hold to jump higher" without the fiddly logic or extra velocities. Here's a snip for the entire bit. >How did you come up with that solution? I'm sure I saw it somewhere before but I don't recall now. There was some frog platformer I took a lot of inspiration from years ago that had wall jumping that felt good, I might've gotten it from that. >>942 >What were you trying to accomplish? A teeth gnashing platformer. I didn't have a strong idea in my head after I shelved the tower survival idea so I ended up just throwing some different mechanics together and tried to make them work. >Where did you hit or miss your objectives? I probably over succeeded in the teeth gnashing aspect. While some anons were kind and commented they liked the level design, that was the most rushed aspect (about one day) and I committed on it too soon. I did have a few friends play test and saw there were some early difficulty spikes but at that point I felt like I wouldn't hit the polish I wanted burning a day or two more. When it came down to concessions made in the remaining time I opted for effects and things instead of level design which in hindsight is a bit of a failure. As one café patron put it 'it's a well put together game but really frustrating'. In general I need to do a better job of either setting expectations or being more serious about interpreting how friends trying it feel. Not to sound like I'm after a pity party or anything! Overall I'm happy with what I got done in the time and it gave me things to think about for next projects. >What caused your results? Easy: I wasted the first week meandering with ideas which I'm very inefficient with. I seem to do best just starting and going from there. Unfortunately life things didn't sync well with the start of the jam so I felt I had to do something to stay invested.

Message too long. Click here to view full text.

Open file (42.42 KB 800x600 drmagma2.png)
>>942 >What were you trying to accomplish? My aim by joining the jam was to both try something I hadn't before and to get my feet wet with C(++). I decided to keep the scope simple to make sure things were achievable with my lack of experience. >Where did you hit or miss your objectives? The game is fundamentally as I imagined it, all my specific targets were met. Of course there are things that I want to resolve and improve in the future. Certain implementation details and bugs weren't fixed, the falling platforms and boss battles are the most janky in that respect. I also didn't get the difficulty curve completely right, with some big spikes in there that can easily turn into slaughter houses. Providing more configuration options, preferably in-game is something worth doing also. Finally it would've been better if the sprites were integer scaled, uneven scaling definitely hurts the game's appearance. >What caused your results? Leading up to the jam I went through some surface level C & C++ tutorials, this allowed me to get straight to work without being obstructed by unfamiliar syntax. Using Newt's template provided the jumping off point I needed as a beginner and allowed me to make fast progress, though in the future I want to try working from scratch. My simple scope meant that I didn't have to refocus my efforts, which cut down on project time not spent getting towards the end. I tried to have particular objectives for each week and stayed focused on the area being working on, this meant that I didn't get sidetracked in different aspects of the game until it was specifically time to work on them. The mistakes I made can be attributed both to my general inexperience and my hesitance in delving too deep into the underlying codebase, if I had been more willing to break and fix things I could've resolved at least some of the issues. >What should you start, stop, or continue doing? In the future I need to be more willing to work on the important structural parts of a game, I also need to integrate the feedback I've received into future projects. Going forward there's always more to know and I must keep trying to learn new things and put them to practice.
>>942 >What were you trying to accomplish? Just, like... make game. Seriously though, what we wanted was to make and release a game. You discover things, both good and bad, by going through a complete release cycle that you wouldn't be able to discover any other way. More specifically, what we aimed for as outlined in >>712 was: >a fast-traversal platformer >where you have to escape a pursuer >with some original character sprites and >at least one piece of original music So this now brings up the question of what a "game" is. I'll sidestep all the tangly stuff that can come with answering that question by simply saying what we wanted was to have a game that >worked on a "toy" level by being satisfying to control >had a win and loss condition >had characters >had a story of some kind, however thin

Message too long. Click here to view full text.

Open file (2.03 MB 2048x2048 ClipboardImage.png)
>>962 >Strange to think Strange to think that character animation would seem easier than background tiles, but that was just how we thought of it. >weird Godot shit One place where we were unfair to Godot: The segfaulting in the Linux export was the result of using an older machine where Vulkan was way behind. Narrowed the problem down to a particular GPU particle spawning and somehow crashing lavapipe/llvmpipe, which the program fell back to in absence of a Vulkan-compatible 3D card. Testing the Linux build on Ubuntu 22.04 with Godot 4.1 instead worked fine, likewise a macOS build taken from that version. Godot is great in many ways, provided you don't stumble into one of its skull-splittingly horrible long-standing-yet-utterly-neglected bugs or under-/mis-documentation... which, given enough time, you absolutely will. Again, no other game engine experience to compare it to, but it didn't live up to its own hype in many ways. Still, discovering that the Linux problem was the VM's fault and that the macOS build worked went a long way towards our not ditching it for future projects.

Open file (530.02 KB 1284x804 laserpointer.png)
Open file (11.86 MB 1282x802 stairs_again.webm)
Open file (6.70 MB 1282x798 clamp.webm)
Open file (14.18 MB 1282x798 swim.webm)
Open file (1.73 MB 1920x1013 metrics.png)
Anon makes an MMORPG (LOL) yesdev 07/07/2023 (Fri) 06:21:01 No.914 [Reply]
Alright, I said I'd stop shitting up the progress thread so here it is. I'm beginning to plan to prepare to lay the preliminary groundwork for an old-school 3D MMORPG in the vein of Everquest, Meridian 59, Ultima Online, and others. I'm pretty much rolling it from scratch, using Raylib for a lot of the input/rendering/sound/etc. functionality plus a few more libraries for XML handling, UDP networking, serialization, and that's about it. You can see some project background and the progress up to this point in the progress thread starting from here: >>755 Spent some time yesterday working on the character controller. Getting capsule -> mesh collisions working wasn't too bad, but getting proper FPS style movement out of it was a fucking nightmare. I ended up raising up and shortening the capsule so it wasn't colliding with everything and anything, using a raycast from the center down to handle different surfaces and steps and the like, while using the capsule to collide with walls/ceilings/very steep slopes. Played with the swimming a bit too, still some funkiness with getting in and out of water. Some shots showing part of the setup for developing the movement metrics - slopes to test walking up and down steps without skipping and bumping, as well as test walking into slopes too steep to traverse. Also got some steps to test what heights the player should be able to automatically step up onto without jumping. TODO: handle sliding down steep slopes, determine jump height/distance, and support crouching and movement on ladders. I would like to use crouch to enter low/tight spaces, hide from enemies (LOS is currently handled with a ray from eye to eye), as well as disabling walking off edges when crouched, so you could carefully approach a cliff edge and look over if you wanted to, or move carefully on a narrow/icy ledge or something. Will be dumping progress here from now so keep an eye out.
6 posts and 12 images omitted.
>>946 Tested with a 22 x 22 x 22 grid of evenly spaced AABBs (total of 10648). I was a little worried at first when I saw 4.5-5 ms time to cull, but then I remembered I was building with debug flags and no optimization. Rebuilt with -O2 and got ~1000us. Culls 10648 down to about 1400-1500 visible by the way. Seems to work well enough for now. Time to actually get some complex terrain and entities in here.
>>943 From the looks of it, you gotta generate collision mesh either way. Or you can have "minimal" height, which probably look better. If player character Z position stays within minimal range, it doesnt visibly change. Ideally you will have torso stay within range, and legs will bend when needed. Not sure how it would look with small ramps tho, but you can figure it out. Also, benefit of collision mesh is loading what player will be able to see from it. Also, easier solution, is to not give small objects collision.
Open file (308.91 KB 1285x805 oct1.png)
Open file (89.43 KB 1284x805 oct2.png)
Open file (1.95 MB 1284x804 octree.webm)
Octree implemented. Got to thinking and came to the conclusion that you can't really get around using one. Got the idea of how to implement properly from thinking about how I would bin each mesh triangle into its respective "chunk" without duplicates or gaps, when I split the zone terrain mesh(es) for rendering/loading. I start by loading all of the models/meshes/whatever. Then, I get an AABB that encompasses them all exactly, which is easy enough, you just find the smallest and largest mesh x point, smallest and largest mesh y point, etc. Then, if I'm encompassing more than 8 meshes in that AABB, I split that AABB into 8 dividing by the length, width, and height. That gives me 8 new AABBs, which I bin the meshes into according to their AABB center point (again, simple to calculate). Then, I recurse, which of course, means for each child AABB, I resize to properly enclose the mesh AABBs, then see how many their are, if more than 8... and so on. I use some flags to indicate empty/leaf node/etc. too. Memory management handled with shared_ptr, as in each Octree has "std::shared_ptr<Octree> nodes[8];" which are instantiated as needed. No malloc/realloc bullshit. The idea for mesh chunking is basically the same except splitting in on a regular 3-dimensional grid, then sorting and re-meshing the tris in each according to originating mesh/mesh material. Those smaller meshes, of which there may be thousands, can then be view culled with an octree. Next thing I have to think about is how to calculate chunk <-> chunk visibility without it taking hours to weeks to "bake". I said before that I'd like to stream the world geometry to each player as they need it. I just have to determine exactly when they need it, based on their position/heading. Have to re-do the collision mesh chunking to work with this octree too. Screenshots - first one is what the whole "zone" looks like. Red boxes are the octree's encompassing AABBs, green are actual mesh AABBs. Second shot and video are what the world looks like through the eyes of placeholder guy.
Open file (104.66 KB 1200x900 capsule_explained.png)
>>948 There is a collision mesh. Or do you mean a simplified, collision-only mesh? I have no plans for any kind of inverse kinematics and I don't really want the feet clipping into the ground any more than they do now (which I spent a long time getting right). I made this pic to show exactly what I'm dealing with. The top half shows some of the problems encountered with a "naive" capsule collider implementation. On flat ground it behaves ok. However, on stairs it's all sorts of fucked. You can get stuck in a floaty halfway-between-stairs state, plus you can't ever really approach the side of the step. On slopes too, you will always be floating a bit off of the ground and it gets worse as the angle increases. Not to mention the way you fly and bounce going down a slope. My approach is the bottom half. I use a capsule for normal wall/ceiling collision, and a ray for ground collision/detection. Raising the capsule lets you get right up to the edge of steps, then "pops" you up to the next one immediately with no "in-between" state - you're either on one step or the other. On slopes, too, it places your origin position exactly on the z-axis value of the slope at that point. I also use a longer ray when moving horizontally or downwards, to detect and "clamp" the player to the slope so you don't bounce down it. The only "bug" I've encountered so far has been falling down into small gaps that the player shouldn't normally be able to. I'm confident I can figure something out though, without radically changing the approach. If I'm missing something obvious though, let me know.
Open file (4.77 MB 1282x800 octree2.webm)
>>949 Thought it would be cool to show the frustum so I gave it a try.

Open file (94.66 KB 642x482 bb4.jpg)
Open file (30.86 KB 640x480 bl1.png)
Open file (106.72 KB 640x480 bl2.png)
Billy's Quest for Love. june 2023 yesdev 06/09/2023 (Fri) 18:40:14 No.738 [Reply]
https://ily888.itch.io/billys-quest-for-love instruction manual → https://shithole.neocities.org/gggg.html UPDATED JUNE 2023!! r18+ nudity , drugs and course language. Guide Billy in his life searching for love. go to school, interact with the residents of the village, and find love! maybe.. Your choices will affect later events. Working time clock 1 sec is 1 min. game ends on the 5th day. the usual game flow goes like this: go to school in the morning, wait for it to get dark outside, then go to sleep in the bed, repeat until day 5. Controls: Arroy keys to move. z is accept/interact. x is menu/cancel. Bugs:-flying the airship over doors will get u stuck. -dont press any directions during scripted events like the intro, u will get stuck. update 2023: -fixed skipping school bug. -removed save from menu. -removed garbage from pocket watch.

Message too long. Click here to view full text.

Moved to progress thread >>749 Will lock this one and let it slide down the board for now. Let's keep these sorts of update posts to the progress thread. If someone wants to make a "showcase" thread for people to shill their completed projects, that would help. If not, I'll make one.

Open file (178.36 KB 1247x1024 tools1.jpg)
Open file (2.20 MB 1920x926 view_from_anor_londo.png)
Open file (1.89 MB 1920x927 metroid_prime.png)
Open file (1.23 MB 1920x867 highpass.png)
Open file (2.03 MB 1920x865 soldunga.png)
Tools Thread - post em up yesdev 04/23/2023 (Sun) 02:26:15 No.563 [Reply]
All-purpose tools thread - post anything you found that's useful to you. 3D/2D CAD, image editing, digital painting, animation, audio/music creation, level editing/design software, the essential game developer's toolbox. I came across these two sites a while back, online 3D game level viewers. The first is noclip: ht tps://noclip.website - a site where you can load up levels from a decent list of games and fly around in them, no-clip-mode style. Some very cool stuff in there, gives you a nice "behind the scenes" look into how your favorite game levels were put together. Definitely check out the Dark Souls maps there, absolutely brilliant. The level of detail put into far away parts barely visible is nuts, try to find all the low-poly firelink shrines there are, visible from other sections of the game. The other is a similar tool, but for Everquest maps - ht tps://eqmap.vercel.app/ . Awesome old-school, low-poly, 90's BSP/CSG-type levels, if you're into that. Check it out and get a look at the kind of claustrophobic, meandering MMORPG dungeon maps that existed before narcissistic 3rd-person cameras took over. What are you using, Anon? What's your workflow look like?

Open file (11.94 KB 384x288 Game Screenshot.png)
How does this look? New Game Demo 01/26/2023 (Thu) 23:41:16 ID: 9cca7d No.463 [Reply]
Not spoiling anything, but how does this look?
>>463 It looks a bit plain. The look could work with more detail (especially the background), maybe add some shading, round off the hard angles and perhaps add an outline to the character? You should show some other parts to give a more complete impression.
>>463 Looks like it's made in Scratch.
Found the game, I don't think the guy who made the post actually made the game. still cool though. https://scratch.mit.edu/projects/792294181/
If Anything The Creator Could've Leaked It To One Of Their Friends, since this image was before the game was made and also didn't have variables.
One suggestion I would give if this is the creator though is decorations in the background, since that could be accomplished in scratch.

Open file (5.79 KB 833x750 Screenshot (615).png)
Star Sentinel nodev 12/24/2022 (Sat) 21:15:00 ID: 4e94e5 No.434 [Reply]
Hiya /agdg/, I have this neat GBstudio game that I made. Its called Star Sentinel. Its only $4.99. It has 13 levels. You can see the gameplay in LV 2 in the picture. You can get it here: https://gamejolt.com/games/Starsentinel/763601
7 posts and 1 image omitted.
>>434 game is now free
>>457 Please stay encouraged Anon. This kind of effort is always a process, be patient. Congrats on your game BTW, please keep working on it! Cheers. :^)
>>459 I'm clueless about programming and just happened to be wandering through here but will second this. Your enthusiasm is commendable, but it takes a lot of time and effort to hone your talents no matter what field you're working in. Keep pushing yourself further and don't give up what you're passionate about. I wish you the best of luck.
Since you shared it for free now, I'll share some thoughts after my playthrough. The game was very basic, this isn't an insult or complaint, just an observation. The ducking mechanic seemed mostly irrelevant except for a couple of levels. As can be seen in the OP pic, those platforms to jump on/over do not provide cover from enemy fire. They probably should. The level in the enemy ship had platforms that were difficult to notice, blending in with the background. Maybe that was intentional, to suggest alien design the protagonist is unfamiliar with. Despite the special medial droid treatment received at the start of the game, there are no upgrades for weaponry or health. Also, only one level seemed to have a health top up. Perhaps at a certain point, after clearing the science lab, a choice ought to be offered upgrading health or weapon power. The virus in the computer level was very sensitive, adding difficulty in an awkward way. Just a slight tap on an arrow key could overshoot the target area quite easily. I'd suggest making the maze more complex instead, with a finer degree of control for the cursor. As for the thick health bar at the bottom, it looked odd. I would make it thinner and stick it in a corner. Probably give it a percentage too, or have it change color, starting green and turning red at the lower end. The music was pretty good, gave an appropriate vibe. Story-wise, it was solid enough I suppose, considering the length of the game. These areas had the strongest potential for expansion in my opinion. The game starts abruptly, it could begin with more of an introduction to the ship and character. The same goes for the enemy, flesh them out more. Generally, I think you have a decent basis for making something here. As suggested by someone earlier, look at other games offered both freely and for money on such sites. It will give you an idea of the competition and what is considered worth paying for. The slightly Metroid vibes I got suggest to me this game could have an action sci-fi horror element if continued with. Overall, a simple and brief diversion, lacking some refinement and complexity but showing some promise. Keep at it and who knows what you'll end up with.
>>461 >>459 >>460 If it helps, some of my future work is going to be history and aftermath. I might make some of these changes and introduce them in an update eventually. I dearly appriciate your feedback. BTW the first few levels are meant to be way, way, too basic because it was meant to give you a feel for the controls.

Open file (29.20 KB 739x432 seasonsmemorial.PNG)
Open file (27.98 KB 732x423 seasonstitle.PNG)
Seeking developers for ZZT game Somebody 09/04/2022 (Sun) 07:40:02 ID: c8f9b9 No.426 [Reply]
If you have any experience in ZZT game development, or are willing to learn (8th graders made their own games with ZZT-OOP), then I am looking for help finishing my ZZT game "Seasons". I will be handling storyboarding and planning. I've got a couple pieces of it done, but at the rate I'm doing it all myself I won't get done before I turn 40. Even if you help make ONE board it will be greatly appreciated and you'll be credited appropriately.
Any progress? Can you opensource it on GitHub?
Open file (1.10 MB 900x1440 1669166482831026.png)
I am a decent programmer, I can write in Lua, C99, Common Lisp, Java and I have some expierence with C# in Unity and Python in Pygame too. I would like to help if the project is completely public domain, otherwise I would consider it unethical to contribute.
>>453 If you find this doesn't pan out, please come help us build robowaifus then, Anon. https://alogs.space/robowaifu/
Open file (392.37 KB 1220x2048 1669349891198917.jpg)
>>454 Robowaifus sound awesome, thanks for giving me the link, I will look into it in my spare time and help you guys out - at the end a robowaifu is a great dream of mine too.
>>456 Y/w Anon. There's a large degree of crossover between vidya dev, and several of the sub-domains for robowaifu creation. Mechanics (as in the physics involved in bipedal humanoid motion & control), and character acting are a couple of good examples of this.

Open file (1.14 MB 1920x1080 watahi102.png)
Demo day? nodev 01/10/2023 (Tue) 17:57:29 ID: 06ef55 No.455 [Reply]
Where's everyone gone?

Open file (231.56 KB 367x360 1459208217184.png)
Deveropa 08/06/2020 (Thu) 23:09:48 ID: fd7b24 No.299 [Reply]
Ok, seems like I'm a fucking retard and this is above my head, so I was hoping that /agdg/ can help me. I've been learning a bit of python as I made some visual novels over the years, I thought I had it ok but I'm stuck with what potentially be something stupid only because I bite more than I could handle. I'm trying to do a simple "Breakout" style mini-game for a new visual novel I'm developing. The gameplay will be largely inspired by both Touhou bullet hell and the original 4 or 5 touhou games that were more in the breakout style. I wanted to have the main character hold a shield and him being able to hold it and toss it, holding the shield would protect him from some projectiles, but he can toss it to damage enemies to either the right or left using the mouse buttons. He should be able to move freely through a portion of the screen, and he would get upgrades through the game like extra shields, more health, and the strength of the shield, and there would be a couple of boss battles using these mechanics. I had the flow map already planned, but the problem is FUCKING REN'PY DOESN'T HAVE SUPPORT FOR PYGAMES ANYMORE Reading some of the documentation, it seems like using creator-defined displayable is the way to go, but I for the life of me can't manage to display the mini-game correctly. Can /agdg/ walk me through this like a retard? Any example code lying around? There are plenty of pygame breakout games around, but I couldn't find a single one ported to ren'py in order to at least see what I'm doing wrong. My other option is moving to godot and trying, but since the game will largely be mostly a visual novel/trainer game, I think it would be pretty retarded to switch engines only because of the mini game, and ultimately I may drop the mini game, but man, I don't want to since I really like the concept.
Sorry it's nothing personal OP, but I didn't reply till now simply b/c I don't do Python. C++ is a much more common language for game dev AFAICT. Good luck with your quest though.
The documentation in Ren'Py regarding 'creator-defined displayable' is very straightforward to me. The creator-defined displayable is supposed to be a canvas to allow the programmer to draw anything. If you don't understand how to program your breakout game with Pygame, you absolutely will not do it in Ren'Py with the creator-defined displayable. If you don't understand the example in the documentation, you absolutely will not achieve your aim in Ren'Py. I won't hold your hand in the details of getting this done. I will leave these hints to you: 1. Figure out how to draw a simple static (a non-moving, non-changing) colored square with the creator-defined displayable. 2. Figure out how to animate that square (move it, change size, change color, change opacity) 3. You should be able to draw multiple objects onto your displayable 4. Program a breakout game with Pygame, not Ren'Py. This is so that you understand the principles of programming and drawing a game to a screen 5. You should be able to port that logic of the breakout game onto Ren'Py's creator-defined displayable.
>>299 There is an engine called ursina, m8
>>436 Thanks!

Report/Delete/Moderation Forms

no cookies?