Coop game development

This forum is for artists to post their music and graphics or discuss artistic matters that could be used in Uzebox games.
Trihook
Posts: 6
Joined: Fri Jun 15, 2018 9:33 pm

Coop game development

Post by Trihook » Fri Jun 15, 2018 9:49 pm

Hello, I have been tracking this project for a while now, and I think it's time to register and post here. This project is pretty awesome and I like it a lot.
Anyway, I'm a pixel artist, and I'm looking for a coder/game designer to make a small game together. This is a hobby for me, so I can draw when I don't work, I'm by no means a pro artist but I do like them retro pixels!

I'm open to discussion about projects that are half way or are still in the concept stage, so send a message or post here.
Here is some art I drew:

https://i.imgur.com/WASXnFI.png
https://i.imgur.com/npJDVVh.png

https://i.imgur.com/ke34Xt0.png

https://i.imgur.com/1sW0tDt.png

https://i.imgur.com/dCb9ve9.png

https://i.imgur.com/xbFC3AW.png

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Coop game development

Post by D3thAdd3r » Sat Jun 16, 2018 8:38 pm

Really good art there! If I could commit I would be interested in a joint venture, but probably I wouldn't be able to devote enough time in the near future which I wouldn't want to do to someone. Out of curiosity, what type of games are you considering or interested in? One of those looks nice for something similar to Catlevania, except better as it is all original.

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Coop game development

Post by Jubatian » Sat Jun 16, 2018 10:11 pm

Huh, nice and quite diverse stuff, I see you have a couple of experiments with attribute mode (2 colors / 8x8 tiles).

To start, you should possibly look around in the existing video modes of Uzebox, notably a lot of them have nonsquare pixels, which gives a bit of extra challenge for graphics design. Video modes on the Wiki

There is also an experimental video mode not yet on the Wiki: Mode 52 (a better demo is a few posts below the image). This has roughly square pixels, at 2 bits per pixels with some attribute and palette swapping capabilities.

For coarse design, you have to keep in mind the limitations: for a small game, the 60Kbytes ROM limit is probably the most important (which determines how much graphics you may afford), the 4Kbytes RAM limit becomes important related to the amount of sprites you want to move around. For larger games, the 4Kbytes RAM becomes even more crucial. You may choose to use the SPI RAM extension, which allows for some techniques to enrich especially a larger game, and there is also a unique video mode utilizing that (Wiki link).

Most of us have the most experience with Mode 3, however by your work it looks like you wouldn't necessarily prefer this mode (tiles take lots of ROM due to the 8 bits per pixel, and you can not have too much sprite content).

Anyway, the point is that you need to consider the possibilities on Uzebox to select the most appropriate graphics design and style for your game! I might be able to help with coding, but the initial approach is often more crucial, to have a good idea which could likely also fit!

Trihook
Posts: 6
Joined: Fri Jun 15, 2018 9:33 pm

Re: Coop game development

Post by Trihook » Sat Jun 16, 2018 10:24 pm

@D3thAdd3r
I'm indisposed in the next 10 days-ish but should have some free time during the summer. The mockup I linked was imagined as an action platformer, but with a bit more exploration, partly inspired by joe gunn (c64) mechanics. The problem with a metroidvania is that I never designed such a game, so something that leans more to an action platformer would maybe be better, as the gameplay and design considerations are much harder to do properly for a metroidvania. So if you want to make something akin to the nes castlevanias, I'd be interested, but if you are leaning more towards the GBA or PS1 castlevanias, then you'd have to take a large role in the design.

Since this is probably something that isn't going to be monetized, time constraints on the development are less of a concern for me.

@Jubatian
There's a lot of modes for the uzebox and new ones are being added as time passes. There isn't a specific one that suits the mockups, but since I prefer small sprites and a limited amount of colors I'm sure a way could be found to accommodate the game itself. The castlevaniaish mockup is roughly imagined as a 320x240/320x200 in screen size, 32 fixed colors, one background plane made out of 8x8 tiles with 2 colors per tile, 8x8 sprites which are 3 colors + transparency. If uzebox can't handle the specs, the resolution can be downgraded and/or the color count reduced to 16 colors. I'm not a coder myself, just an artist, so these specs would be discussed and planned before any game development takes place. Personally, I'd rather sacrifice resolution than the color count, as the resolution with such small sprites is mostly used to have a larger view of the game world. Flip screen vs scrollable BG is a solid tradeoff I'd make in a heartbeat if it eases the development.
The aspect ratio of the pixels is something I'd prefer to be as square as it can, because with notably less square pixels, the artwork would need to be redrawn.

User avatar
L4rry
Posts: 239
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Coop game development

Post by L4rry » Sat Jun 16, 2018 11:36 pm

Hey Trihook! Welcome to the Uzebox club. Your art work looks really awesome.

So I'm L4rry, as you can see from my handle :P. I've been hanging out here for a while.

Your request has me interested, because I've wondered for a while if my games might
be improved with better graphics. My skills are in coding, not graphics. Opposite to you :)

I don't have a half way game I can share, but I do have a full game called Iros that is in desperate
need of better graphics.

If you are interested, I welcome you to improve the graphics for it in whatever style you see fit. Even if you just trace over
what I've done. It would be a good learning curve for the platform too I think and I would love to see the game presented via someone
that's clearly competent in graphic design!

Here's the game: https://nicksen782.net/a_demos/Emscript ... gameid=219

Code and graphics can be found here: https://github.com/lawrencebrooks/iros

Regardless, welcome :)

Trihook
Posts: 6
Joined: Fri Jun 15, 2018 9:33 pm

Re: Coop game development

Post by Trihook » Sun Jun 17, 2018 12:13 am

When the time permits, I'll contact you and we can prolly work something out. I can't promise you anything but a finished game is much easier to work on than designing everything from scratch, so I'll prolly try my hand at it in about 2 weeks. My work is kinda chaotic, so I can't give you anything more specific than that as to the time frame. From the source files, it seems about a weeks work of gfx, give or take a few days.

User avatar
L4rry
Posts: 239
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Coop game development

Post by L4rry » Sun Jun 17, 2018 1:21 am

No it's all good :) Take your time and make sure you do what you feel is right with the time you have. I just wanted to throw an option out there :)

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Coop game development

Post by Jubatian » Sun Jun 17, 2018 7:05 am

Trihook wrote:
Sat Jun 16, 2018 10:24 pm
@Jubatian
There's a lot of modes for the uzebox and new ones are being added as time passes. There isn't a specific one that suits the mockups, but since I prefer small sprites and a limited amount of colors I'm sure a way could be found to accommodate the game itself. The castlevaniaish mockup is roughly imagined as a 320x240/320x200 in screen size, 32 fixed colors, one background plane made out of 8x8 tiles with 2 colors per tile, 8x8 sprites which are 3 colors + transparency. If uzebox can't handle the specs, the resolution can be downgraded and/or the color count reduced to 16 colors. I'm not a coder myself, just an artist, so these specs would be discussed and planned before any game development takes place. Personally, I'd rather sacrifice resolution than the color count, as the resolution with such small sprites is mostly used to have a larger view of the game world. Flip screen vs scrollable BG is a solid tradeoff I'd make in a heartbeat if it eases the development.
The aspect ratio of the pixels is something I'd prefer to be as square as it can, because with notably less square pixels, the artwork would need to be redrawn.
There are difficulties here, and we are already very near the edge of the hardware's capabilities.

The first three mockups are something which Mode 52 might be able to handle (I would suggest planning with 256x192 resolution at that, matching the ZX Spectrum's, offering plenty of free RAM and CPU time even with many sprites to allow for easier planning). It has got a Color 0 attribute mode, so the background tiles could be made using Color 0 and Color 1 (which latter may be set black). You can then use 3 color sprites: Color 1 + 2 + 3, with Black being nice for sprite outlines. The difficulty is that the two other sprite colors are the same for all sprites, anyway, it can replicate a nice ZX Spectrum look and feel without attribute clashing on the sprites.

Otherwise for square pixels a limitation is the timing of TV output, which means you have about 224 visible scanlines, the scanline height being fixed. On the Uzebox, about 4.67 cycles per pixel would be square, Mode 52 has 5 cycles per pixel. 320 square pixels don't fit on a TV screen! Old microcomputers which had 320x200 resolution had 0.86:1 pixel aspect ratio (pixels are narrow), emulators often just don't care of this. The equivalent mode on Uzebox is Mode 40/41/42 (but those are character modes without sprites), and also Mode 90 with a unusual 6 pixels tile width.

It isn't possible to have more freedom in colors in these modes.

For 8 bit color with sprites, it isn't possible to realize anything better than Mode 3, which (extended resolution) is 5.5 cycles / pixel or 1.18:1 pixel aspect ratio. This might still be passed for square pixels for some material, however where aspect ratio is important, the distortion would show. You can have 256 pixels width.

For 4 bit color with sprites, the best resolution is 6 cycles / pixel, currently Mode 13 realizes this. You can have 224 pixels width if you want it all being certainly visible (240 pixels possible, but often it gets cropped on the left / right on televisions).

Mode 74 and 748 realize 4 bit color at 7 cycles / pixel, which is an exact 1.5:1 pixel aspect ratio. You may check it out in my game, Flight of a Dragon, which shows off the most what these modes could look like when used for a graphics-intensive game (this is Mode 74, the game doesn't use the SD card, it is all in 60 KBytes). You can have 192 pixels width.

Designing for 1.5:1 pixel aspect ratio is probably the easiest of all the non-square pixels, you can set up Gimp for this (there is an article on the Wiki for this), if you try to rework something existing, it means what previously was 3 pixels, now has to be drawn on 2.

If you really don't need "high" resolution, double scanning might be an option.

Then for square pixels, you would have at most 144x112 resolution (9 cycles / pixel), but at this, just about anything is possible. It is up to you, nowadays there are several fantasy consoles and other designs dealing with such very low resolutions (often 128x128 like the Pico-8 and similar), it is up to you.

Trihook
Posts: 6
Joined: Fri Jun 15, 2018 9:33 pm

Re: Coop game development

Post by Trihook » Sun Jun 17, 2018 8:28 am

There is certainly a lot of options on offer here ^^
As for the pixel ratio, it only matters when drawing circles and arches, so if you want a those you want to check the aspect ratio to get a circle and not an oval. IMO anything from roughly 0.80:1 to 1.20:1 doesn't warrant a redraw of art assets for non arched things.
I'm not as tech savy as you coders out there and I don't understand much about how many cycles the pixels and colors cost. With this qualifier, can you please offer an opinion on these specs, and if they could be pulled off on uzebox?

16 color global palette
2 unique colors per BG tile.
8 sprites of 4 colors each, could be explained as two 1 bit sprites (this would mean 16 sprites in total) overlaid on top of each other, one using 2 fixed colors (black and transparency) and the other one using 2 unique colors.
What kind of resolution could one get with these specs?

I'm pretty sure a custom screen mode would be needed for such a thing, so can you tell me how does one design a screen mode? I'm not at all knowledgeable about these types of things, so I don't even know what questions to ask =S

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Coop game development

Post by Jubatian » Sun Jun 17, 2018 9:07 am

Trihook wrote:
Sun Jun 17, 2018 8:28 am
There is certainly a lot of options on offer here ^^
As for the pixel ratio, it only matters when drawing circles and arches, so if you want a those you want to check the aspect ratio to get a circle and not an oval. IMO anything from roughly 0.80:1 to 1.20:1 doesn't warrant a redraw of art assets for non arched things.
I'm not as tech savy as you coders out there and I don't understand much about how many cycles the pixels and colors cost.
The cycles / pixel figure for a graphician is just the Uzebox way of identifying the pixel aspect ratio. 4.6667 cycles / pixel is exact square, the rest are as follows:
  • 3 cycles: 0.64:1 PAR, Mode 9 (text mode, huge ROM cost), ~460 pixels visible
  • 3.5 cycles: 0.75:1 PAR, 1bpp modes in Mode 748 and Mode 72, 384 pixels visible. NTSC C64 HiRes is the same.
  • 4 cycles: 0.86:1 PAR, Mode 40/41/42, Mode 90, ~340 pixels visible. CGA, Amstrad CPC and several others, the typical 320x200 mode.
  • 5 cycles: 1.07:1 PAR, Mode 52, Tornado 200, ~280 pixels visible. ZX Spectrum is about the same (using 256x192).
  • 5.5 cycles: 1.18:1 PAR, Mode 3 (extended resolution), 256 pixels visible. Most of us here can use this mode.
  • 6 cycles: 1.29:1 PAR, Mode 1, 3, 13, ~230 pixels visible.
  • 7 cycles: 1.5:1 PAR, Mode 72, 74, 748, 192 pixels visible. NTSC C64 Multicolor is the same.
Trihook wrote:
Sun Jun 17, 2018 8:28 am
With this qualifier, can you please offer an opinion on these specs, and if they could be pulled off on uzebox?

16 color global palette
2 unique colors per BG tile.
8 sprites of 4 colors each, could be explained as two 1 bit sprites (this would mean 16 sprites in total) overlaid on top of each other, one using 2 fixed colors (black and transparency) and the other one using 2 unique colors.
What kind of resolution could one get with these specs?

I'm pretty sure a custom screen mode would be needed for such a thing, so can you tell me how does one design a screen mode? I'm not at all knowledgeable about these types of things, so I don't even know what questions to ask =S
Mode 52 is the nearest to this as of now.

You can access all 256 colors in it, there are 4 palettes of 4 colors, color index 0 and 1 can optionally be selected for every line, for a normal background + sprites graphics, you can have 1 color attribute (so the background color has to be fixed, typical for Spectrum or Commodore 64 HiRes games, and your mockup is also alike, a fixed black bg.). Sprites are 3 color + transparency.

For sprites there is a limitation: on the Uzebox you don't have actual sprites. The sprite graphics is drawn on the "canvas" like in "modern" games, for conversing RAM and CPU time, using tile-by-tile allocation (when you ask for a sprite, the tiles it covers are copied into RAM and the sprite is drawn over). That's why the background's color selection is limiting sprites. Sprite count is limited by available RAM (how many tiles can be copied off) and CPU time (taken by drawing the sprites), you may look at the Li-2 demo to see an example of what Mode 52 is capable to do.

There are an other breed of lower resolution modes which work differently, Mode 2 (2.14:1 PAR, 144 pixels wide), and Mode 72 (1.5:1 PAR, 160 pixels wide). These work like old graphics processors with a limited number of sprites per horizontal line, but you can select colors independently for sprites (in Mode 72).

If you really want 2 free to select colors per Bg. tile, even if the mode was possible, you would be quite low on RAM. Then a tile would have to be specified by 3 bytes: Tile index, Foreground color and Background color, for a 256 x 200 surface without scrolling, that would take 2400 bytes. True that a 16 color palette would allow the Foreground and Background colors to fit in 1 byte, but it needs more code to decode those colors, which can't be fit into a "high" resolution video mode.

If you only needed such freedom for static screens (such as images in cutscenes), Mode 52 has suitable capabilities (there is an option in it to display with 2 attributes or 3 attributes per tile), but those can only work with graphics in RAM (so you would have to store the background in RAM, no room for too much sprites and likes, these options are really intended for image display, possibly loaded from the SD card).

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests