Just a little game demo

[ultifinitus]

Here's The Demo: http://sourceforge.net/projects/ultiscroll/

video here: http://www.youtube.com/watch?v=5fmsEOaan64


The source is included, messy but decent. The controls are ridiculous ->
arrow keys = movement
x = jump
z = increase max xvel
leftclick = drop a block
space+click = bounce block
0,1,2, or 3 = change next block
ctrl+z = undo.
q = delete blocks under mouse.
ctrl + r = respawn

What do you think? I need suggestions, if you would be willing to give them. I am implementing scrolling and I'm updating the collision system in the next couple of days. But I'm wondering if you would like to see any features added?

[Return 0]

Nice job... I would like to see the player get squished by a block and have his sprite get flattened like a pancake. :)

[ultifinitus]

Oh thank you!

Haha that would be pretty interesting. I could probably actually implement that. Anything else? Were the graphics up to par? Did you like the controls? Should I do anything more with the physics?

[thepedestrian]

Jealous. I so want to be able to do something like this. :P

Awesome work mate. This is amazing. :)

Graphics are pretty good for a simple game like this. Controls are also very easy. I'm not sure about the physic aspect of the game.

[ultifinitus]

Wow thank you! I really appreciate the positive remarks!

I'm going to adjust the physics and upload a new version tomorrow afternoon. Also I'm wondering, do you think I should have it room based? So say I make it a sort of puzzle/action adventure game, and each time you go offscreen in any direction it leads to a new room. Would you enjoy that more than having it scroll to follow where your character goes? Or should I stick with scrolling?

Also I would like to know, if I add an rpg aspect to the game, should I make it something spell based? In other words, should I just stick purely to the sidescrolling adventure story thing, or should I add fighting/spellcasting to the mix and allow your character to be upgraded and basically increase longtime playability while decreasing short time playability.

[NGen]

The room system gives a visible way to determine where you'll spawn if you die, I suggest rooms.

The game itself looks to be doing fairly well, are you using a combination of the SDL and OpenGL? If not, then you're going to have a difficult time implementing that 'squash' effect without creating a new sprite for it.

[ultifinitus]

I am using purely SDL, I know of the downfalls, and they are numerous and unfortunate... However I'm a decent graphic designer and I don't mind making new animations for things like this. Then again it would make it nice to have the rotation and resizing and hardware acceleration of OpenGL, so I may end up switching.

Okay I'm not sure if I'm going to have any sort of 'shooting' capability. When I decide that I may decide whether to keep the rooms or not, but I appreciate the input. Of course if I was just being purely lazy, as far as my code goes, rooms would be a few degrees easier than scrolling.

Back to coding =)

[Duthomhas]

Sorry if this is off-topic (cool stuff, bro), but what's the music you've got playing in the demo?

[helios]

I don't mind making new animations for things like this. Then again it would make it nice to have the rotation and resizing and hardware acceleration of OpenGL, so I may end up switching.

A sprite of, say, 32x32 can be rotated in any angle with bilinear interpolation in just a couple milliseconds by using a linear transformation. Using the same method, you can scale and the sprite in any direction. The drawback is that you either allocate memory for the new sprite, which takes time, or you blit it to an existing surface, which is more complicated.

[ultifinitus]

A sprite of, say, 32x32 can be rotated in any angle with bilinear interpolation in just a couple milliseconds by using a linear transformation.

Helios, I love you. I'll just write a function to load all rotations into separate surfaces- then call that rotation based on the equations I've already written. it's perfect! Do you have any recommendations for zoom?

@Duoas:
The music is by musicshake(which is not actually a band but a sort of music gateway thing), but it was quickly audioswapped and I can't find the track again- if you would like I'll see if I can send some emails and find out what song it is, I forgot the track as soon as I swapped it unfortunately...

Alright, I've tentatively decided room based for the map system and I'm going to seperate the map creator from the game soon. Also I am going to implement some very interesting features that everyone may enjoy =)

[helios]

load all rotations into separate surfaces

Are you sure that's wise? If you can spare the memory, fine, but I think you'll end up using a lot of memory just to save very little CPU. It'll be even worse if the sprites are animated.

I have a class system for software surfaces with thread-safe reference counting which you can have, if you want. I wrote it when I got tired of debugging leaked SDL_Surfaces and race conditions when drawing to the screen asynchronously. You can do things like

Surface a("bitmap.png");
//Shallow copy.
Surface b=a;
//b and a point to the same surface.
b=b.rotate(pi/3).scale(1.5,.5);
//Same as above, only with fewer memory allocations:
b=a.transform(Matrix::scale(1.5,.5)*Matrix::rotation(pi/3));
Surface c(640,480);
c.fill(Color(0,255,0));
c.over(b); //alpha blending
//void f(const ConstSurface &);
f(b);

ConstSurface is a reference to an immutable surface. Surface derives from it and adds a few methods, such as over() and fill(), that modify the surface.
There's also a const-safe interface to access the surface at pixel level.
The price is that you have to remove all direct SDL calls involving graphics and threads, but you get safe versions back.

[ultifinitus]

You are correct in the lack of wisdom in pre-caching all of the rotations, I just didn't want an inefficient jumble of code if it was possible to avoid it. Of course I have no idea why I hadn't thought of multithreading the image system- now it seems inevitable.

Oh and I would greatly appreciate the class system! I'm sure you have some awesome code written.

[NGen]

Ultifinitus, may I ask what your CPU specs are? If you plan on expanding on this game much more, using software-based transformations will only prove to slow down your game if you don't have a CPU that can handle it.

[ultifinitus]

NGen, My specs are sub-par, and I plan on allowing others to play said game with limited resources. I agree that it will continue to slow as I add software transformations, however I have limited time and I want to have something playable before I run out of time =/

I will look into both aspects, the software implementation would be much easier from a coding perspective, but much more processor intensive.. Hardware implementation would take more time on my end, but it would end up being better in the long run- so if I can learn quickly (I usually do), I will- However if it takes more time than I have available, I'm afraid I'll have to stick with super slow software =)

I'm taking an unfortunately long time making decisions on some aspects of the game, but development continues.

[helios]

I just watched the demo video. That's pretty cool. I like how the blocks bounce up and down.

I don't agree with NGen for two reasons.
1. The SNES was able to do linear transformations with nearest neighbor in real time.
2. LTs are very rare operations in most 2D games. You aren't going to have over 9000 megapixel sprites rotating at the same time. At any given time there'll be one, maybe two small sprites rotating slowly.
But a cleverly designed abstraction layer can let you operate on layers regardless of where the graphical operations are performed. (*Wink-wink*)

[ultifinitus]

Thank you helios!

Well I'm glad that there is hope yet for this linear transformation system.
I believe that you are referring to preforming calculations on the graphics card or the processor, which would be awesome, I would have to go beyond SDL for that wouldn't I (would I)? Wow, this doesn't happen often, but I may be slightly baffled.

[NGen]

When I said expanding, I meant further use of software-based transformations. If they begin to use them extensively I could definitely see the FPS dropping noticeably. But I'm paranoid with that sort of thing. I'm sure that when you stated 'in just a couple milliseconds' you meant in a shorter period of time than that, since you're probably aware that 16ms is the time-frame that games get in order to maintain 60 FPS. If 'a couple milliseconds' is the case, then I'd severely limit the transformations done, as it will build up very quickly.

I'm just making sure ultifinitus is aware that with software-based rendering such as the SDL you're missing out on plenty of features which are faster than the SDL implementation in certain cases.

I believe that you are referring to preforming calculations on the graphics card or the processor, which would be awesome, I would have to go beyond SDL for that wouldn't I (would I)? Wow, this doesn't happen often, but I may be slightly baffled.

The interface that you would deal with would not be all that complex. SFML simplifies a lot of it for you and provides rotation, color-blending, and polygon rendering (all are a part of OpenGL anyways) with a miniscule performance hit, something magnitudes of times smaller than software-based rendering. 'Magnitudes' is obviously relative to the computer that the program is being ran on, but my point is that there are faster and more powerful alternatives that would really not require much more programming on your part. If you don't plan on doing much with these transformations, then stick with the SDL. There's no point in switching to a different library if the relative advantages will be minimal. But in the future keep SFML in the back of your mind.

[ultifinitus]

No worries- thank you for further explaining your stand, and I will keep SFML in the back of my mind- I'll look into all of the options and decide the best route for this project.

On another note- I may be adding enemies today!

[chrisname]

SFML is a really good library, I really would consider using it over SDL. If you've separated the UI from the game logic properly, it shouldn't be that hard to convert to SFML without changing any actual game code. I would definitely try and learn it for your next project.

You can find SFML downloads here: http://sfml-dev.org/download.php
And tutorials here: http://sfml-dev.org/tutorials/1.6/
There is also documentation you can read.

[ultifinitus]

If you've separated the UI from the game logic properly

Haha, well I think I've separated the two decently (not spectacularly) and hopefully I'll be able to implement SFML without too much difficulty.


I'll look into it now. What do you think is the general learning curve?