Vapourware Codexian Game Development Thread

[shihonage]

Learning C++ is going well so far. I hope to be to the point of learning SDL by April or May. After I finish that, I’ll begin working on a project of my own.

I use SDL. It seems slower than Microsoft's sprite-handling interface in DirectX9, however it's cross-platform and is sufficient for many 2D tasks.

 

[zwanzig_zwoelf]

 

[Bad Sector]

BTW, isn't the game finished? Is this bonus content, side story, sequel, or...?

 

[Wayward Son]

BTW, isn't the game finished? Is this bonus content, side story, sequel, or...?

Sequel iirc

 

[Viata]

DLC. Now that he is a succesful developer, he is already doing DLCs.

 

[zwanzig_zwoelf]

BTW, isn't the game finished? Is this bonus content, side story, sequel, or...?

It's finished, but I decided to add an alternative ending to spice things up.

 

[Zep Zepo]

It's been a while since I've worked in 2D (sprites and stuff)

And I start to want to move stuff around the screen...and everything is moving slow as a fat ass.

And I think...I must be missing something,, I check, i'm running timer code to update at 60 FPS. Fucking sprites are crawling across the screen like my grandmother.

And then it hits me, back in the good old days when I published games to magazines, I was working on vic-20, c64, atari, etc.. and as I recall, moving my sprite positions during vertical blank, I was only operating in 320x200 screen space and everything was snappy, in fact I had to slow most shit down.

But like I said, then it hits me, I'm now operating in 1024x768 and beyond. 4 times as much (or more) travel than back in the day. so a 60 pixel move at 1024 width at 60 FPS is pretty damn slow.

Maybe it's just me, but I'm quite sensitive to things that don't appear to be moving smoothly, for example moving a sprite 5 pixels in a go instead of 1 pixel, to get up some speed. It just looks wrong to me.

I've found scaling things up, or zooming in the camera gives me somewhat the speed I'm looking for, but then everything is blocky and shit and drives me nuts again. Perhaps I need to redraw the sprites to look less like at as I scale up.

Thus ends this blogdex.

Zep--

 

[Zed]

I know what you mean Zep. One of the reasons why I keep making my little games and prototypes in 320x; 640x max. Ok, 800x max.

Regardless. If I do sprite movement at higher resolutions, I usually do the 5+ pixels jumps running in functions that still only handle 1 pixel nudges.
Err.
So I do a function that moves the object on x or y by 1 pixel. Stop and move 1 pixel back on the same axis if it collides or whatever. These little nudge functions are instantaneous.
What I then do is call them in chunks of 5 times, 10 times, or whatever, in one go (frame), depending on what speed I want.
If it moves 3 out of 5 pixels before collision it stops the 5-loop at 3 and returns whatever the heck happened (touched wall, enemy, whatever).

At least this is my approach with 4 direction movement. 8 directions and more, and I'll do the same thing but throw in some cos/sin math that I will never remember off the top of my head.
The biggest problem if it's tied to FPS, the difference between these integer values can be too big. It's either crawl or run fast as hell. But there's no reason for 320 games to run at high FPS tho. Again something in favor for lower resolutions.

Not a very scientific answer but my point is that I agree that there's a convenience in just being able to run 1 pixels nudges at a high FPS.

Also anything I draw that isn't pixel graphics looks like shit. Lowres ftw.

 

[Zep Zepo]

That's actually a good idea, I think i'll mess around in 640x and see if I can bear if or not.

Zep--

 

[Zep Zepo]

That's actually a good idea, I think i'll mess around in 640x and see if I can bear if or not.

Huh..erm. I must be doing something wrong setting the screen size. It gives me a 640x window..but the pixels are still in 1024x768 (or whatever), so still just as slow, even tried setting to full screen, same shit. Some investigation is in order for tomorrow...

EDIT: I guess it's more like I'm setting the window 'size' instead of actually changing the resolution, which is what I want, ie: bigger pixels, not the same shit in a smaller view port.

Zep--

 

[vdweller]

New game is out

https://store.steampowered.com/app/1007880/BALL/

 

[zwanzig_zwoelf]

Nice game, but homoerotic prose puts me off.

 

[vdweller]

Nice game, but homoerotic prose puts me off.

Still better than Deadfire

 

[zwanzig_zwoelf]

Nice game, but homoerotic prose puts me off.

Still better than Deadfire

Well, at least your game is centered around pounding instead of being an annoying, shoehorned gimmick.

 

[Wayward Son]

Nice game, but homoerotic prose puts me off.

What you don’t like playing with bouncing balls?

 

[zwanzig_zwoelf]

Nice game, but homoerotic prose puts me off.

What you don’t like playing with bouncing balls?

There's a risk of them touching each other.

 

[Punch]

I know what you mean Zep. One of the reasons why I keep making my little games and prototypes in 320x; 640x max. Ok, 800x max.

Regardless. If I do sprite movement at higher resolutions, I usually do the 5+ pixels jumps running in functions that still only handle 1 pixel nudges.
Err.

Lowres ftw.

Do everything in in-game coordinates with your own measurement unit, then transform and normalize the coords in relation to the 2D "camera" position/ratio before actually drawing stuff into the display framebuffer, you mad lads.

 

[Zed]

I know what you mean Zep. One of the reasons why I keep making my little games and prototypes in 320x; 640x max. Ok, 800x max.

Regardless. If I do sprite movement at higher resolutions, I usually do the 5+ pixels jumps running in functions that still only handle 1 pixel nudges.
Err.

Lowres ftw.

Do everything in in-game coordinates with your own measurement unit, then transform and normalize the coords in relation to the 2D "camera" position/ratio before actually drawing stuff into the display framebuffer, you mad lads.

i dont understand what you mean but it sounds unnecessary.

there's X and Y cords unless you're doing a 2d game in a 3d engine. just keep position and movement related to those, whats wrong with that?

 

[Punch]

I know what you mean Zep. One of the reasons why I keep making my little games and prototypes in 320x; 640x max. Ok, 800x max.

Regardless. If I do sprite movement at higher resolutions, I usually do the 5+ pixels jumps running in functions that still only handle 1 pixel nudges.
Err.

Lowres ftw.

Do everything in in-game coordinates with your own measurement unit, then transform and normalize the coords in relation to the 2D "camera" position/ratio before actually drawing stuff into the display framebuffer, you mad lads.

i dont understand what you mean but it sounds unnecessary.

there's X and Y cords unless you're doing a 2d game in a 3d engine. just keep position and movement related to those, whats wrong with that?

It's OK to have your "in-game coords" simply be measured 1 unit = 1 pixel and not do any fancy stuff, but it's good to be doing stuff by arbitrary units so you actually remember to keep in-game logic and shit independent from the screen resolution so you avoid the "my character moves fast from one side of the screen to another in 640x480, but in 1920x1080 it's too damn slow", it's easier to scale graphics up and down in a consistent manner if you change resolutions or per user config request. Even if you hate non-pixel perfect scaling you can simply do it in a way that combines viewport and scaling by integer steps when needed instead.

I'll admit that this may not matter at all if the intention is to have all graphics at fixed size on screen at all times and with viewport expansion per resolution always (ie see as much shit as your monitor allows) so my comment was a little bit dumb, but still it's a nice thing to keep in mind as a possibility.

 

[zwanzig_zwoelf]

boo

jammin'

 

[Zed]

It's OK to have your "in-game coords" simply be measured 1 unit = 1 pixel and not do any fancy stuff, but it's good to be doing stuff by arbitrary units so you actually remember to keep in-game logic and shit independent from the screen resolution so you avoid the "my character moves fast from one side of the screen to another in 640x480, but in 1920x1080 it's too damn slow", it's easier to scale graphics up and down in a consistent manner if you change resolutions or per user config request. Even if you hate non-pixel perfect scaling you can simply do it in a way that combines viewport and scaling by integer steps when needed instead.

I'll admit that this may not matter at all if the intention is to have all graphics at fixed size on screen at all times and with viewport expansion per resolution always (ie see as much shit as your monitor allows) so my comment was a little bit dumb, but still it's a nice thing to keep in mind as a possibility.

okay I see what you mean. yeah I only work with static resolutions and then viewport them or something if i want to allow "higher resolutions" (just bigger window with stuff scaled up).

 

[zwanzig_zwoelf]

Made Phantom 3D, a quick maze game for Nokia 3310 jam. 10 levels, should be beatable in up to 15 minutes or so. Enjoy!

 

[Bad Sector]

Now that is an interesting jam, i love retro stuff. I died at the 4th level, despite managing to find two "power ups". The phantom approached me from behind, i only noticed it while i was turning and only saw a few pixels before the game restarted :-P.

I think the game is a tiny bit smooth for the 3310 though .

Reminds me of back when i was in highschool and i got a 3410 (basically a 3310 with Java and WAP) and wrote a small platformer for it that i called "Vurlio World". I actually spent way more time trying to copy it to my phone than actually making the game. At the time i couldn't order stuff from the Internet (and didn't even knew where to look) and Nokias used phone-specific cables to communicate with phone-specific software and couldn't find anything in any retail shop i asked. I eventually found some cable, but while it could transfer stuff like SIM address book, it couldn't transfer MIDlets. To this day i'm not sure if it was possible at all.

I ended up uploading the game to a web server, writing a WAP WML page with a link to it and then downloading it from the phone itself (which was *very* expensive at the time, especially for a student - and i had to call my provider to enable internet support and have them tell me how to configure the device manually... those were darker days).

Sadly i lost the code and i only have the jar/jad files from an old backup of the aforementioned server (the timestamp is from late 2003 but that is most likely the backup date, i think i made the game early 2003). Here is the game running on an old Nokia 3410 Java "emulator", itself running under an ancient version of Java installed in a XP VM :-P (funny enough the actual phone is a bit faster):

Eventually i got 3510 (basically a 3410 with color) and at some point a 6600 which i think was one of the best early smartphones - and IMO the best mobile from a gaming perspective thanks to it having both physical buttons *and* a joystick. Modern smartphones are nice for reading articles and posts on the web, but for me mobile gaming mostly died when physical buttons died in mobiles :-/.

I see the jam ends in 3 days... i might try doing something quick if i do not feel too lazy :-P.

 

[zwanzig_zwoelf]

FYI it restarts the current level if you die. Initially I wanted to restart the whole game, but then decided against it to lean the difficulty to the reasonable side (although bouncing back to the previous level would be more punishing while staying reasonable enough...). And I wanted to make it less smooth, but couldn't decide on the best way to do it apart from limiting FPS to some low & arbitrary value. Still, cranking out something playable in 3 days feels good -- now I understand why so many devs participate in these jams.

Interesting little game you got there. Liked the relaxed pacing of it -- guess fast-paced games weren't an option on these phones. I was a spoiled kid around 2004 w/ my first phone being a Nokia 1100 w/ a p advanced version of Space Impact installed. And I agree -- touchscreens are horrible for anything except for turn-based games. Modern mobile games could be a godsend for a fan of TB tactics, but instead we've got a ton of casual games (and franky, emulating SNES/PS1 games is a better option).

Also, I do remember some maze game on these old monochrome phones, but don't remember the name/manufacturer/model. It was a simple free-roaming 3D maze game with the only goal to find an exit, but I guess you can imagine how infuriating it was with mobile controls and low fps.

 

[Bad Sector]

I didn't noticed the restart at the same level... they all look a bit the same :-P. Maybe show some text when they start with the level name?

Nokia 3410 had Munkiki's Castles preinstalled which took advantage of the phone's 3D rendering functionality (it was software rendering really, just implemented by the phone instead of doing it in Java). I do not remember any other 3D game for these phones although a very simple maze would be possible.

A few years after the game i mention above (~2006 according to timestamps... time sure flies fast) i made an attempt for an FPS on mobiles (where the S would stand for stabber :-P although you'd also cast fireballs). I managed to make a fast renderer, considering the phone's abilities (i remember that the rendering was too smooth for the 3510's screen to keep up as it had very slow response times and everything became a blurry mess the moment you moved the camera):

It used everyone's favorite 3d method for blocky mazes: raycasting. TBH these days i think rasterization would probably be faster, especially with a preprocessed map and would also allow for non-rectangular rooms (ala Doom, although without elevation differences), but it would require way more work on the tool side (and i do not think i even considered at the time).

I also, apparently, managed to make a royal mess of the build process. The above are two of the available configurations, the "high end" at the first two images and the "low end" (even using different assets) at the last image. Since it would be impossible to use the exact code everywhere (for example the Nokia Series 40 phones were faster with 16bit framebuffers whereas the Series 60 used 32bit framebuffers) i wrote a custom preprocessor and build system specifically for J2ME (which i only used for this project). It provided some C-like preprocessor functionality, but it also "knew" about mobile models and their characteristics, SDK locations, resource locations, etc. But all that stuff only worked on the machine i had at the time, i just tried to compile some code and it blew up with tons of errors :-P.

Mobile development was a PITA at the time, i remember i was working on another game (a small top down racing game) and i had on my desk every Java phone i could get my hands on and any emulator i could find... and constantly had bugs coming from the people i was cooperating with (who would handle distribution, etc to different carriers). Sun made a mess with J2ME by allowing third party VMs and having practically zero tests. I eventually gave up when i started getting bugs for phone models whose official emulators would show no issues. Not much later i met someone on IRC whose job was in a company dedicated to testing J2ME games and he told me they basically had a small warehouse of different phones just for testing - which pretty much confirmed my view on how bad things were. As sucky the controls are on Android, you can get stuff working on it with little issues and i find amusing when i read some developers online complaining about the fragmentation on Android :-P.