Platform Racing clone game dev
#21
[Image: FzVlbmH.png]

Cool update for you:
https://files.catbox.moe/90rtyd.mp4
There's (some) items that (partially) work! I gave them some little placeholder icons (an art pass will be done later trust me breh) The most functional of which being Teleport. You can now softlock yourself for the first time (as seen above)!! Yay!!!
Lightning and Laser Gun are not functional, if you can see them there! Sorry!
I also got rid of my annoying cursor! Sorry about that!

Additionally, Crumble and Mine Blocks now work closer to how they should  Bow
[Image: aGf8Xvh.png]
The Following 2 Users Say Thank You to Northadox For This Useful Post:
  • Adulock77, oxy
Reply
#22
I wish i wasnt so ADD when it comes to focusing on projects. Game dev looks fun.
The Following 1 User Says Thank You to Rei For This Useful Post:
  • Northadox
Reply
#23
(5th October 2021, 6:06 AM)Delphinoid Wrote: This looks really cool! Do you have it on GitHub? I've been working on something (kind of) similar for a while, so I'd be super interested to see what your stuff looks like so far.

I don't have a public Git repository up yet; I'd like to be a little further along first. I do eventually plan on releasing it as free/libre software as I said but it needs a bit more time in the oven. There are a few things at the moment which are pretty inefficient that I'd like to iron out first, and some of my coding habits might be pretty cringe

(5th October 2021, 6:06 AM)Delphinoid Wrote: don't believe the lies, C++ is a garbage language 

uh, based?
[Image: aGf8Xvh.png]
Reply
#24
I used to shit on C++ too but i mean. If used right its fine.. I wrote an entire UI lib and front end OS for the switch in CPP.. would've been needlessly time consuming to do in C. And this is from someone that does most shit in C. lol.
Just think, at least its not pyshit :p
The Following 2 Users Say Thank You to Rei For This Useful Post:
  • Delphinoid, Northadox
Reply
#25
Hello, sorry for the lack of updates. I was busy with Other Things™ and there hasn't been much progress....
However, here's something cool: a public git repository, just for Delphinoid!
https://github.com/Mythradox/free-racing
Sorry if you CRINGE at my bizarre ways of formatting 99% of lines to be less than 80 characters long, my bizarre header file habits, my absurdly inefficient code and the like. Feel free to fix it if you're so great.

On the priority list is finishing all the PR2 blocks and polishing player movement with original art and animations. Then I'll finally move to the GUI. Following that I'lll see if I can do level I/O so you play levels more easily without them being hardcoded in. Then multiplayer and server. Then maybe add some more blocks and features. And polish polish polish.
[Image: aGf8Xvh.png]
The Following 2 Users Say Thank You to Northadox For This Useful Post:
  • Delphinoid, Rei
Reply
#26
Im just happy there are other people out there besides me that still writes makefiles.
The Following 2 Users Say Thank You to Rei For This Useful Post:
  • Delphinoid, Northadox
Reply
#27
are you gonna make the blocks SVG too?
since in the original they go rly pixel-y when u zoom in but character does not
á
The Following 1 User Says Thank You to Camer the Dragon For This Useful Post:
  • Northadox
Reply
#28
(25th October 2021, 11:23 PM)Camer the Dragon Wrote: are you gonna make the blocks SVG too?
since in the original they go rly pixel-y when u zoom in but character does not

This game's artwork will be raster, not vector; you'd essentially have to rewrite a whole graphics engine that can read in .svg files/vector graphics ala Flash, which I don't intend on doing.
[Image: aGf8Xvh.png]
The Following 2 Users Say Thank You to Northadox For This Useful Post:
  • Camer the Dragon, Delphinoid
Reply
#29
(26th October 2021, 10:01 PM)Delphinoid Wrote: This is awesome, thank you for putting it on GitHub! I like how it's clearly outlined how to compile it and set it up, that's something I never end up bothering with. I do have a couple of comments on some technical(-ish) problems that can be easily fixed btw, although you're probably already well aware of these.

1. I'd strongly recommend uncoupling updating and rendering, especially if you plan on making this multiplayer eventually. You should ideally have both a target framerate and target tickrate. The reason for this is just because if someone can't maintain the desired framerate at all times, they'll fall behind. You might then think, "well that's a simple fix, I'll just make everything happen faster at lower framerates"! This is somehow an incredibly common "solution" that pops up frequently even in heaps of AAA titles, but it introduces a nasty framerate dependency on the game physics: as well as making the physics non-deterministic, it also makes them susceptible to blowing up at low framerates or breaking at high framerates. The best solution is to just have the game update and render independently.

2. If you plan on supporting Windows, it's probably best to let go of SDL_Delay, as it has a tendency to oversleep. Iirc, this is because the implementation of SDL_Delay on Windows doesn't correctly change the timer resolution before sleeping. Fortunately it's not too difficult to write a custom timer that fixes this.

I just realized you're using SDL for rendering rather than OpenGL; I had actually completely forgotten it was even capable of simple drawing instructions! It's been a long time since I've used it in anything drawing related, so I can't really offer any advice on that unfortunately. Back when I used it like that, it didn't support hardware acceleration, but I think it might now so it should be fine.

I'd also like to have a proper look at some of the game code later too, it's super interesting looking through all of this!

Thanks for the response!

The two issues you mention are pretty much the one and the same, and the solution is just as you mentioned of having a proper timestep. This is mostly a learning experiement first and I'm too much of a BAKA to immediately know how to add it. Shouldn't be too complicated, hopefully.

I've not really gotten my hands dirty with raw OpenGL so I can't say how it compares, but SDL is simple to interface with, has great documentation, is relatively popular, is portable and Works on My Machine™ so I'm rolling with it.

The biggest problem I would say the actual game code has now is how it handles "active" blocks (that is, the blocks visible on screen/update in accordance with the player or the blocks' own behavior). The rest...should be acceptable, hopefully. Outside the context of game code, there's probably something that can be done with tidying up the #includes, but proper header file organization to me is a wasp nest I'm too afraid to even poke with a stick. And whatever you do, don't look in G_COMMON.h unless you want to be spoiled on gameplay features I intend on addding!!!!!!1111

I know Donkey Kong 64 did something like the gaffe you mentioned in issue #1. That's your random trivia for today.

Oh, and if GitHub ain't your thang, I've also put up my own handy Gitea instance, just in case you're a fellow M*crosoft hater:
https://git.doxsite.xyz/Mythradox/free-racing
[Image: aGf8Xvh.png]
The Following 1 User Says Thank You to Northadox For This Useful Post:
  • Delphinoid
Reply
#30
UPDATE

YES I am still working on this, I chiefly wanted to Make Things Work™ before I went about discussing things.

Here's another video of the racer racing through a level I crafted showing the game's features. It took a needless amount of time but things Now Work™. Though there are some minor issues. I'll resolve 'em later.

Since last time:
  • Added a "mouselook" feature. You ever play Hotline Miami? It's a 2D game, but you can use the mouse there to view more of the level, and the same applies here. I think this is a great feature to add for a future PR installment because one issue I've always felt is that I couldn't see enough with PR2's incredibly strict camera. AspectZero was telling me one time that he has one of his hands on WASD and the other on arrow keys while he's playing (and if you don't know him he's a le epic PR2 god) and this change would make it so you either have one of your hands on WASD or the arrow keys (as one would have to be on the mouse), so maybe this could be optional. If you hadn't noticed before, there's a bit of extra camera panning based on the racer's horizontal velocity done to help alleviate that problem of not being able to fully see where you're going, but this gives a lot more control. Sorta-related, but "not being able to see where you're going" is kind of a meme also frequently discussed in discourse about classic Sonic the Hedgehog games...might as well resolve it here too
  • You can now click to teleport somewhere like in PR2's level editor (this would obviously be disabled in a normal game)
  • Added bumping. It should work just fine for non-upwards bumping (like shooting a block with a laser gun or slashing with a sword, both unimplemented atm) but we'll get there
  • Preeetty much fixed most problems with the previously mentioned "persistent block" system; it now uses a doubly linked list and allocates/deallocates blocks to the heap when need be instead of whatever I was doing before. Hopefully this system will work?
  • Added swimming! Physics on it aren't great but it is indeed swimming.
  • Added crawling! It should MOSTLY work as it does in PR2.
  • Added the bubbling sound effects from PR3. Yes, this is a very important change.
  • Added a custom player sprite instead of the low quality .jpeg of the Classic Set I nabbed off of the Jiggmin Wiki. His name will be "Playboy" (har har funny). In the future, I think having spritework would be best rather than scaled-down larger images, but tell me what you think about the design at least.
  • More things I'm probably forgetting or intentionally not including because they're too specific or minor
Rotate Blocks are the only (pre-PR3/Motley Monday) blocks left to add, and their implementation would be...tough. Well for me at least.
I want to add a proper timestep as Delphinoid and I have conversed about, that's next. Then polish. Yes.
[Image: aGf8Xvh.png]
The Following 2 Users Say Thank You to Northadox For This Useful Post:
  • Delphinoid, Magyar
Reply
#31
Very important feature
[Image: aGf8Xvh.png]
Reply
#32
Will there be a way for level makers to turn off the mouselook thing on their level?
i failed the mario twitter challenge
The Following 1 User Says Thank You to ThePizzaEater1000 For This Useful Post:
  • Northadox
Reply
#33
(7th November 2021, 10:45 PM)ThePizzaEater1000 Wrote: Will there be a way for level makers to turn off the mouselook thing on their level?

I suppose it could be both a player aand level option, though if you're doing something like one of those quiz levels where you shouldn't be able to see the correct path for the question you could just acknowledge the fact that players can mouse look and build the level around it
[Image: aGf8Xvh.png]
Reply
#34
Tbh for quizzes now (at least in PR2, whether this has it I don't know) you could just use teleport blocks and put the answers quite far
so no need for mega long arrow trails
á
The Following 1 User Says Thank You to Camer the Dragon For This Useful Post:
  • Northadox
Reply
#35
(8th November 2021, 2:22 PM)Camer the Dragon Wrote: Tbh for quizzes now (at least in PR2, whether this has it I don't know) you could just use teleport blocks and put the answers quite far
so no need for mega long arrow trails

there you go, thinking outside the box
teleport blocks are on the agenda with this but I'd need to add some sort of "block settings" thing first for their color
[Image: aGf8Xvh.png]
The Following 1 User Says Thank You to Northadox For This Useful Post:
  • Camer the Dragon
Reply
#36
(8th November 2021, 2:22 PM)Camer the Dragon Wrote: Tbh for quizzes now (at least in PR2, whether this has it I don't know) you could just use teleport blocks and put the answers quite far
so no need for mega long arrow trails
Generally in PR3 we just cover the bottom of the answer thing for the quiz with depth 1.01 art so you can't see if there is the good stuff or the bad stuff.

Speaking of art, what do you intend to do for that?
i failed the mario twitter challenge
Reply
#37
(12th November 2021, 8:40 PM)ThePizzaEater1000 Wrote: Generally in PR3 we just cover the bottom of the answer thing for the quiz with depth 1.01 art so you can't see if there is the good stuff or the bad stuff.

Speaking of art, what do you intend to do for that?

Rather than programming a whole drawing system what I intend to do is that you'll be able to export your level's blocks as a bitmap image and then using your art program of your choice you can just draw over that, and then you'll be able to specify the depth of each layer through some file or something.
[Image: aGf8Xvh.png]
Reply
#38
wow!
Zooming in/out and added some particles.
Of course, you've got your standard brick/crumble block debris and the particles that come out of ya with Speed Burst, but I also added a nice new personal touch - there are now particles that indicate when 1) you're accelerating (blue lines like the slipstream mechanic in Mario Kart), 2) you've reached full speed (the little spark, akin to the one in Super Mario 3D World when you've hit max dash speed), and 3) you're still at full speed (dust). I hope these are good additions that will add some much-needed visual flair, though I can tune them a bit if they're too intrusive.
[Image: aGf8Xvh.png]
The Following 1 User Says Thank You to Northadox For This Useful Post:
  • Magyar
Reply
#39
Today I added some preliminary level editing functionality.

Capture the Overseer, anyone?

Additionally, before this, I also fixed the timestep (ish) so it no longer uses SDL_Delay, now using a more proper tick-based system. It's probably not ideal as it is now but it's certainly better. I also refactored the code a whole bunch.

Does anyone know a good way of handling I/O of like big tile-based levels? A custom format or maybe using something like JSON or XML? I mean it's probably pretty easy but it's just a matter of the best way of going about it. I was going to ape PR2's level file style but upon fetching a level file I have no clue what all of the numbers exactly mean. Confused I don't think people would want to manually edit a header file and recompile the whole executable just to play a level they've made, which is what I've been doing.
[Image: aGf8Xvh.png]
The Following 1 User Says Thank You to Northadox For This Useful Post:
  • Magyar
Reply
#40
Very cool! I'm sure you'll release this game before the actual PR4 comes out!!
a casual human being.
I come online here every 4-5 months or so. But hey. JV is still alive!
The Following 4 Users Say Thank You to Magyar For This Useful Post:
  • Adulock77, bls1999, Camer the Dragon, Northadox
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)