I forgot to post my gameplay video here, so I thought I’d do that:
http://www.youtube.com/watch?v=JGOSOg8nQMc

Great entries guys, looking forward to those postmortems.

Much better. I made it to level 2! Thats good!

Sweet. Good to hear you made it to level 2. I’ve heard it’s impassable.( haha, guess I have to make things a little bit easier.)

But the game crashes when I try to enter a high score.

Hmmm, interesting, I’ll look into the highscores issue. I know it crashes if you try to play a newgame after getting a gameover. (which is fixed now, but I don’t think I’m going to post another build within the hours I have left of the contest)

Much better. I made it to level 2! Thats good! But the game crashes when I try to enter a high score.

-Matt

Just in time! I’m busy composing my all of my reviews, and was going to post them all at once later tonight. I’ll play your new build first.

-Matt

Ack! Update… I’m a bit late

I finally got another build up. It seems like most people have already voted, but I still have 24 hours.

In any case, I would like feedback, so please download it. Thanks!

http://syntropymac.googlecode.com/files/Syntropy_uDG.dmg

Update

My entry was deleted from the list of games, but I should be able to re-add my game to the list. (according to Carlos)

I thought I would post my game (in fairness) here though in case it doesn’t go through til later and I’ve already made updates to it.
http://syntropymac.googlecode.com/files/Syntropy.dmg

It’s a ways off from being complete, but it’s the work I’ve done up til the deadline.

[edit] oops! forgot a readme here’s extra control info:
A = Use (accelerate without an ability)
S = Jump
D = Absorb
Down + A(use) (while running) = slide
Up + A(use) + D(absorb) = Release ability

Progress Video Update

Check it out here: http://www.youtube.com/watch?v=a3L_C49qoyE

It’s getting down to the wire, hmm 17 days or so left?

Stuff I plan to work on:
Sliding (I’ve been holding this off)
more Graphics (tiles, walls, ladders etc)
sound fx
Portals
Finish implementing “baddie” characters along with new main player graphic, and monster graphic.
Level Transitions
High Score List

looks like I’ve got quite a bit of work…

I’ve recruited two musicians to compose some music for me:
Adam Skower (http://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendid=97803949)
Brandon Russell (no portfolio, but I’ve got some good stuff from him already)

That brings the team up to 4 members, including myself and Tyler.

Update
I’ve finished creating the level editor (screen below w/ download), and am now coding the enemies into the game. No build because I’ve decided to improve upon some of the features. I think my most recent build wouldn’t do my work any justice, so without having to point out every caveat about what I’ve coded versus what you can actually play, it’ll just have to wait. I do realize that if I don’t release another build at least three weeks before the deadline, I could run into some trouble, so I’m keeping that in mind.

Level Editor

Level Editor Download

Level Editor Instructions:
I think its fairly straight forward for the most part.
For moving and removing sprites you have to double-click. (move: double-click, hold and drag)
To scroll the stage you can use the left and right arrows.
When you load levels it doesn’t remove the current level. (i did this on purpose)
so you’ll have to delete the level if you want a clean canvas.

bugs/issues
The edit fields on the side actually can’t be edited you have to use the arrows.
You can lay multiple sprites on top of each other. (there’s no limitation on layering or colliding sprites)
Changing the layer order of sprites in a level after its been loaded can be done however, newly created sprites
won’t be included in the layer order.
That’s about all.

Common Enemies
These are some of the creations Tyler made for the game.

(From Left to Right) Jingle Jangle, Skully, Matchead, and Hungerpain.

Information:
Jingle Jangle: This guys crazy, he runs up and starts biting you.
Skully: This guy will drain synergy of your current ability.
Matchead: Runs around frantically when perturbed, then explodes.
Hungerpain: Waits around for you to pass him, then eats you and spits you out.

More stuff to come:
In addition to these updates I’ve also added some things to a youtube channel where I will show some progress vids.
build d0.7.8 progress video

Nick Lockwood - 28 January 2009 10:07 AM

Tim Cool - 22 January 2009 10:12 PM

[You’ll notice that there is no such thing as a pointer in REALbasic. It kinda sucks, and you can fudge a function pointer using a delegate, but for objects it seems like there’s no luck. (at least to my knowledge) Here is a way I handled an issue which would have been easier with a pointer:

if (not Sprites.Item(TimeIndex) isa HUDText) or Sprites.Item(TimeIndex).GameType<>1 then
//"isa" is a nice command, and returns a boolean from checking if an object is an instance of a class    
for i = 0 to Sprites.z_spriteUbound
//This can be fairly expensive, but the condition above makes it ok in my book
      if Sprites.Item(i) isa HUDText and Sprites.Item(i).GameType = 1 then
        TimeIndex = i
        exit //speeds things up a bit
      End if
    next
  End if 

The code above looks for the timer text on the HUD, then assigns the TimerIndex to that object’s place in the array, which is then used for:

HUDText(Sprites.Item(TimeIndex)).Text = Format(World.Time, "000") 

Using the name of the class, you can access specific attributes of an object inherited from an array of super objects. (scope) Because the sprite surface item array is dynamic I can’t just assume the position of the HUD’s timer isn’t going to change. So my method is no pointer, but it kinda fudges one.

You seem to have a misconception about what an object is. In RB (like Java) every object is actually a pointer to an object. So when you call Sprites.Item(TimeIndex) it is returning a pointer to the sprite, not a copy of it. There is nothing preventing you from assigning that to another variable and using that variable to refer to or modify the original sprite later.

The only differences between these pointers and the ones in C are that a) they are inexplicit – you don’t have to dereference them manually you can just treat them as values as long as you know that when you copy them from one variable to another you are copying the reference not the value, and b) they are garbage collected – when the last reference to an object is deleted the object is deleted too ( there are also WeakRef objects which don’t prevent the object they are pointing to from being destroyed if all other references are deleted).

So when you create your HUDText sprite, just assign it to a global variable called TimeSprite or whatever, and you’ll be able to refer to it from anywhere in the game whenever you want instead of going through that tedious lookup loop every time you need to find it again.

Nick

Yea, I’ve already been over this in the RB forum. Thanks for owning me again though, haha jk.
I originally thought that SSS was creating a copy of the object in its Append method, which caused a lot of my confusion. I do realize now that I just need a global variable. I think the only way the method I created would be useful is if something were being created and destroyed dynamically and you needed to reference it, like a particular particle…. not sure when you would need that though. (and you’re right it is kinda tedious)

Tim Cool - 22 January 2009 10:12 PM

[You’ll notice that there is no such thing as a pointer in REALbasic. It kinda sucks, and you can fudge a function pointer using a delegate, but for objects it seems like there’s no luck. (at least to my knowledge) Here is a way I handled an issue which would have been easier with a pointer:

if (not Sprites.Item(TimeIndex) isa HUDText) or Sprites.Item(TimeIndex).GameType<>1 then
//"isa" is a nice command, and returns a boolean from checking if an object is an instance of a class    
for i = 0 to Sprites.z_spriteUbound
//This can be fairly expensive, but the condition above makes it ok in my book
      if Sprites.Item(i) isa HUDText and Sprites.Item(i).GameType = 1 then
        TimeIndex = i
        exit //speeds things up a bit
      End if
    next
  End if 

The code above looks for the timer text on the HUD, then assigns the TimerIndex to that object’s place in the array, which is then used for:

HUDText(Sprites.Item(TimeIndex)).Text = Format(World.Time, "000") 

Using the name of the class, you can access specific attributes of an object inherited from an array of super objects. (scope) Because the sprite surface item array is dynamic I can’t just assume the position of the HUD’s timer isn’t going to change. So my method is no pointer, but it kinda fudges one.

You seem to have a misconception about what an object is. In RB (like Java) every object is actually a pointer to an object. So when you call Sprites.Item(TimeIndex) it is returning a pointer to the sprite, not a copy of it. There is nothing preventing you from assigning that to another variable and using that variable to refer to or modify the original sprite later.

The only differences between these pointers and the ones in C are that a) they are inexplicit – you don’t have to dereference them manually you can just treat them as values as long as you know that when you copy them from one variable to another you are copying the reference not the value, and b) they are garbage collected – when the last reference to an object is deleted the object is deleted too ( there are also WeakRef objects which don’t prevent the object they are pointing to from being destroyed if all other references are deleted).

So when you create your HUDText sprite, just assign it to a global variable called TimeSprite or whatever, and you’ll be able to refer to it from anywhere in the game whenever you want instead of going through that tedious lookup loop every time you need to find it again.

Nick

Another Progress Update…
Ok, so its been a while since my last post and I figured I would let you all know I’m still working on this. Still no new build, but I’ve decided to post it after I’m done with the level editor. I had been loading the levels from a tif file which gave a nice mini-preview of the level. However, as it turns out a pixel can only hold so much information, and while the way I had level loading setup for the prototype worked out, I need something that can handle more data for these newer builds. Another thing I’m working on is optimization. The game runs alright on my intel Mac, but not so well on my older G4 iMac. My goal is to have it run fluidly on both. For this I may need to reconsider how I handle the way levels are loaded/displayed in the game. Anyway some screens to keep you entertained…

Screenshots

Using SSS in RB
ok time for something useful (for some/few who actually use rb and SSS)
You’ll notice that there is no such thing as a pointer in REALbasic. It kinda sucks, and you can fudge a function pointer using a delegate, but for objects it seems like there’s no luck. (at least to my knowledge)
Here is a way I handled an issue which would have been easier with a pointer:

The code above looks for the timer text on the HUD, then assigns the TimerIndex to that object’s place in the array, which is then used for:

Using the name of the class, you can access specific attributes of an object inherited from an array of super objects. (scope)
Because the sprite surface item array is dynamic I can’t just assume the position of the HUD’s timer isn’t going to change. So my method is no pointer, but it kinda fudges one.

Progress update…
So I remember saying I would post another build by the week after Christmas, but I don’t think I’m ready to release it yet.
It’s been difficult to work on anything the past week being the holiday season and all, so I’ve been fairly unproductive. I have managed to get the Jump working nicely, and the camera to function. I’ve finally gotten around to redoing my collision code, so that there are no “glitches”. I had noticed in my first build that when the player moved too fast he went through platforms/ladders, and some of the ground collision was off. I’ve also replaced the ugly ground tiles with new ones, which look more like they will in the final version.

Here’s some art and a screen shot to keep you entertained:
Some rough concept sketches of the main character done by my artist, Tyler “Sprig” Kadish:

New ground tiles:

Mapping out new collision boundaries:

Hopefully, I will have another build before the end of this week.

Now that my Finals are over, I can begin working on my entry again. I thought I would periodically list some of the main things I am working on at the moment. I also plan on having a small “stuff I’ve learned” section inside of some of my updates. I feel this should help others who are trying to develop a game with RB using SSS (or a logically similar system). By the week after Christmas I’ll have another build of my game. Right now I have several things planned which include:
Working On:
-Camera that follows the player.
-New Tile Graphics/ Larger Tiles.
-Improving Collision detection system.
-Adding the ability to “Jump”.
-Grabbing onto ladders in mid-air.
-Jumping off of Ladders.
-Adding the ability to slide.
-Actually have the monster move through the level. (right now the level is being pulled into him)
-An easy way to implement particles.

Stuff I’ve Learned:
Collision detection can be kinda tricky using SSS because the surface checks for all the groups assigned to the collision checker object after each frame. The problem is that if you have too many collision checker objects, or too many collision groups within one collision checker your game’s performance gets hit pretty hard. I found that a nicer way to handle this is by assigning two collision groups “Player” and “Other” to the collision checker object. This way when the surface solves the collisions it doesn’t have to process as much. The more groups you have per collision checker object the more it compares by (n * (n – 1)) / 2. You may ask then “how do I differentiate upon collision between objects with the group ‘Other’?” The answer is I’ve added a property to the SuperSprite class called CollisionType. When every object is initialized, its CollisionType is set. In the player’s collision event, the code checks for a collision between “Player” and “Other”, then further checks for the “Other” bounds owner’s CollisionType. I think this works well with the type of game I am creating where the player is really the only thing colliding with its environment, but may not work so well if you wanted collisions between other non-player objects. For that you would have to add another group (“Other2?”), and possibly assign every sprite with an “Other” collision bound and an “Other2” collision bound as well.
Note: I’ve taken some stuff out of my code to make it easier to read and relate to what I was talking about.
In the main window.

Inside of the Level Sprite

Inside of the Player Sprite

oh yea, I also forgot to mention…
Game Features: (to be implemented/kinda already are)

Movement in the same vein as “Megaman” (jumping, climbing ladders, sliding)
The ability to absorb the 4 elements (fire, water, wind, earth) to help solve puzzles. Fire: Removes wood, ice, etc. Water: Make plants grow, makes platforms slippery (for baddies and player w/o water absorbed) Wind: Moves platforms, baddies. Earth: Creates ground, removes ground. (similar to Loderunner)
The ability to absorb light/dark energy. Light: Standard “I’m invincible” mode. Also pauses Desumere. Dark: Player becomes interpolated, and can walk through obstacles.
Levels are destroyed as you play through them.
Different elements also have other affects on player. (i.e. absorbing fire increases your speed, wind increases your jump etc.)
Baddies that will stun, push, and hurt you.
Portals lead you to new levels.
Parallax side scrolling.
Particle effects for absorbing elements from a distance.

Syntropy
Genre: Survival/Action/Platformer
Game Description:
You play as an alien trying to survive an attack on your home world. You have to absorb the elements found in your surroundings to get through each level. Think fast, as the super being “Desumere” consumes your planet!

Primary Development Tools:
REALbasic
-SuperSpriteSurface framework
Photoshop
Spriter (custom tool)
Hardware:
iMac 2.4 Ghz Intel
Powerbook G4

Here’s the latest prototype:
Syntropy Game Prototype

Controls:
Movement – Arrow keys
Absorb Element – Space bar

Note:
The current assets used are placeholders (the real game will not feature Megaman nor Megaman/Mario music)

all comments are welcome!