Minigolf Game - Devlog

[crow_riot]

Uhm...can anyone see those images?

nope. 'hotlinking not allowed' ...

*edit*
nice to see it on gamedev.net; hope the traffic doesnt have any impact on the forum here

 

[kurtkz]

Ugh, thanks crow_riot :/ All the other image hosting sites are blocked from my office I'll re-edit the post when I get home. Alternatively, Peter could post the pics here if he gets a chance to do so before me.

Hehe, I don't think the post will get much attention at gamedev.net. Unless you're showcasing SSGI or the latest deferred rendering engine it doesn't seem like projects get much love there

 

[traylorpark]

It looks like I'm the only one who can fend off the alien invasion.

Some excellent images form Kurt! Finally, the colors are correct and expected :lol:
For some reason, the screen1.gif was not loading ... I dunno why.

And .. my Caanoo arrives Wednesday! YAY! Excited to play my own game!

 

[traylorpark]

So I want to share with yall a bit of the process involved in bringing a texture from a graphics editor into the Wiz/Caanoo.

Hopefully, most of this will be technically correct. Kurt (or anybody for that matter, please correct me if I make a mistake).

You start with an image, PNG perhaps. As I understand it, if you pretty stick a PNG into a Wiz, it it’s graphics processor will do its darndest to show it on the screen ... but that means that it will have to convert it into 16bit image (different from 16bit per pixel, or 8bit per pixel in Photoshop).

This causes unpredictable results that usually do not satisfy (though I did have a moment recently where I discovered I liked the converted image more than the source). As a visual designer, we want as much control over the image as absolutely possible.

Therefor, previewing the possible results during the production process is totally invaluable. Before this post, I linked to an excellent piece of software that allowed myself to convert/encode a source PNG image into compatible arrangements of 16bits and preview the various results in a PNG before exporting into the final Wiz compatible file (that retained the correct bit information).

Below, I will detail these different arrangements and their trade-offs so artists can be better informed as to how their texture work will/might be mangled when they stick it on a Wiz

The source PNG. Beautiful. Features smooth gradients and an alpha channel. The right side alpha is a smooth transition. The heart’s alpha edge is nicely anti-aliased. If only this is what we could keep. Unfortunately, we have to make sacrifices.

Encoding at 4-4-4-4.
Check out those gradients. Banding and very horrible dithering. The only benefit to this encoding is it gives you relatively smooth alphas. This can be a strong selling point, hard edged, aliased alpha edges can be very ugly and often produce the dreaded “white halos”. This encoding relieves you of that problem.

Encoding at 5-5-5-1.
Alright, those colors are not longer scaring away children. Banding is visible, but it isn’t going to kill anyone. The problem is now the alpha. The heart on the left does have an alpha, but the edges are rough. Also, note the right side, there is an alpha there, but the edge was cut off hard. There is no gradual fade. Remember, this is also the type of encoding that creates white halos!

Encoding at 5-6-5.
Finally, colors a designer can love. There is a teeny bit of banding and dithering, but not enough to get really worked up about. Certainly, this is a fairly unique situation as long smooth gradients tend to really bring out the worst in compression encoding. The trade-off here is a total lack of an alpha channel. Transparent areas are converted to white (or some odd color depending how the software is feeling). So the heart on the right is just cut off ... and while that part is white ... the alpha does not exist.

Hopefully this will be interesting for a handful of folks. It has lead to some interesting experimenting on my part. Picking and choosing the best encoding for the best situation and working around the trade-offs.

 

[kurtkz]

That is an excellent guide, Peter. I think you should put it up on your blog as well. It's invaluable for people who are designing art for mobile platforms and I haven't really found a similar guide elsewhere on the net. Good job!

 

[kurtkz]

Mmm, I just read GPH's SDK guidelines - all games must run at at least 30fps...I've managed to get the game running at that now. Sometimes it dips below 30fps but for the most part it hovers around 28-33fps. Has anyone asked the guys at GPH if the 30fps is hard lower limit?

 

[kurtkz]

OK, scrap that question. I managed to get the game running at 30fps+...

 

[traylorpark]

Here is my camera proposal I sent to Kurt. Note, this is just a proposal. It does demonstrate how we are imagining a fairly UI free system for swinging the golf club. I'd guess that this method is perhaps more immersive for the player then if we had lines and gauges everywhere.

I'd love to hear your thoughts!



*image links to the video on Vimeo. Please click :lol:

 

[crow_riot]

seems to be very intuitive! i also like the explanation, that could turn out in some nice tutorial

one suggestion: shoulder buttons are a bit pain IMO, could you use A/B on the button side to rotate the camera? i assume it's only rotating around one axis, not more degrees? then there is still the X button available to swing the club.

 

[traylorpark]

Yeah, I don't see why that can't be considered ... perhaps even both! The goal is for the controls to be as non-confusing as possible ... I can even imagine the additional Camera movement with the Shoulder buttons (A/B buttons) to be a bit overwhelming initially. The again, this audience is nothing if not technically adept

If this game were to go really mainstream for some bizarro reason ... I'd probably turn these more "advanced" controls into an option one must enable to use.

 

[kurtkz]

Agreed, the user doesn't *need* to use all the controls - the extended controls are for more "accuracy", I guess?

 

[forces]

I would say, that in the first level, you couldn't use rotating camera, and that option would be revealed at level two, assuming that first two levels would be tutorial levels. I like the design of the white text on a gray background, so it would be cool to have the text on first levels(like in the video), and even when you finish the level, you would see the statistics in the same style. Also, I would lik to see some levels with special stuff, such as bumpers (shoots the ball horizontally), jumpers (shoots the ball vertically).

 

[kurtkz]

@forces/before: The engine supports it, but it's up to Peter as to whether or not he wants to add them

 

[traylorpark]

Oh, I've been thinking about that :lol: I'd really love some ideas on crazy stuff to do! The fun part for me is making those elements fit into the context of the game world. Like, what would a bumper look like in a Tokyo suburb...

And, as usual: Helvetica font = always cool looking. AKA, a designer's crutch typeface. B)

 

[kurtkz]

Hehe, sounds good - let me know what kind of special features you'd like and I'll add support for them. Escalators, jump pads, speed lanes, transporters. You name them, I'll add them

 

[torpor]

Exploding mushrooms! Deep Pits of Infinity! Tasmanian-Devil-whirlwinds (that move)!

GTA-Hot-Coffee-like easter eggs, behind the shrubbery, featuring Japanese school girls (Use your environment for inspiration, like with the shrubbery) .. Death-car mode where the goal is to KILL ALL GOLFERS.

And so on.

 

[traylorpark]

Exploding mushrooms! Deep Pits of Infinity! Tasmanian-Devil-whirlwinds (that move)!

GTA-Hot-Coffee-like easter eggs, behind the shrubbery, featuring Japanese school girls (Use your environment for inspiration, like with the shrubbery) .. Death-car mode where the goal is to KILL ALL GOLFERS.

And so on.

Dude ... you just wrote our press release!

 

[kurtkz]

Hahahaha, classic. Maybe I should post an update to get things back on track, eh?

- added config file (tweak camera settings and such)
- added level format (tweak per material physics, sounds, music, etc.)
- camera works *mostly* as it does in Peter's video, still some tweaking to do

No new screenies yet, but I'll post some as soon as I've finished the camera tweaks. Also, I'll be receiving my Caanoo next week. I haven't made a build for it yet as I need to change some code related to input. Should be fun

Cheers
Kurt

 

[kurtkz]

Here's a sample level file:

TARGETS
	OBJECT=./orangeSemi.md2.cmsh
		SOUND=./eveningCicada.ogg
		SOUND_RADIUS=32
	END
	OBJECT=./greenSemi.md2.cmsh
		SOUND=./eveningCicada.ogg
		SOUND_RADIUS=64
	END
END

The targets section defines the target models the player must hit along the course. It also defines the sound played by that target as well as the range of the sound (you could probably think of it as the volume in a sense).

SCENE
	MESH=./scene.bscn
END

The scene section defines the scene mesh to load. I don't think it needs any other parameters. For now at least...

PHYSICS
	MATERIAL=./bushes_bushes.psd.mtl
		INTANGIBLE
	END
	MATERIAL=./takeLeaves_takeLeaves.mtl
		INTANGIBLE
	END
	MATERIAL=./takeTrees_takeTrees.mtl
		INTANGIBLE
	END
	MATERIAL=./treesBack_treesBack.psd.mtl
		INTANGIBLE
	END
	MATERIAL=./treeTop_treeColorBAKED.png.mtl
		MASS=100.0
		ELASTICITY=0.9
		FRICTION=0.1
	END
END

The physics section defines the physics properties for the different elements in the level. Properties are set per material and are limited to: TANGIBLE/INTANGIBLE,MASS,ELASTICITY,FRICTION. In this example, the tree is made light and elastic. The ball will bounce (quite violently) off the tree

MUSIC
	BACKGROUND=./smallPark.mp3
END

The music section defines the ambient music that is played for the level. Again, no other parameters are required for now.

Cheers
Kurt

 

[torpor]

Its horrible of you to be updating us with all this new and wonderful technology, yet we can't do anything with it!

Please sir, can I beta?