Untitled Platformer - Programmers' corner

Team members, please discuss anything that has to do with programming here.

I think we should flesh out the game idea a bit more before the development starts.

Pushing the game design document and adding details about the audience (who should buy the game/play the game), the main characters in the game, the environment (where and when),...

These are important questions for the gameplay, controls, game physics,...

Is it a story based game?
Is a arcade mode possible? (depends on the audience)

No - these are no pure programmers questions, but they don't fit into the other categories alone either.

Is it possible to make regular geometry that isn't a wmb or model respond to code by selecting one of its flags in properties? I created a level whose certain geometry I wish to fall when the user presses a button, but I'm hoping I can save the step of building this geometry separately then reinserting it into the level.

If you want to interact with things in this engine, it has to be a separate model. You have to assign an action to the entity in order to use the custom flags (flag1-8) in WED. Otherwise there would be no way to query the flags in-game later.

I have my own template project going on. Among the features are a configurable state manager, an inventory and a control setup manager.
I still need to work out some things and improve the flexibility. I don't know if parts of it are useful for this project, but if it is not urgent (means not before march) I'm willing to contribute some of the templates.

Code is built up modular, so inclusion into any project is easy. Lite-C is required, though.

Thank you, this would be great.
Do you like to post some code samples that can be used for a kind of "coding style guide"?

This would ensure that we have the same naming convention, etc.

Well I have my own coding guidelines. If I find some time I can of course illustrate why I'm naming things like I do, but I'm not sure if everyone would be ok with this.

Wenn es zu abgefahren ist, sollten wir davon vielleicht doch lieber Abstand nehmen... War nur so ne Idee, weil du wahrscheinlich die größte Code-Basis zur Verfügung stellst.

Haha... guter Witz. Ich komm seit Jahren zu nix mehr

-----------

Ok I'll try to sum up my naming conventions.

Variable prefixes:

vec - VECTOR
ang - ANGLE
pan - PANEL*
txt - TEXT*
ent - ENTITY*
fnt - FONT*
view - VIEW*
bmap - BMAP*
par - PARTICLE*
snd - SOUND*
(note that engine objects are always pointers, so I did not use a further 'p' prefix to mark it as pointer)

c - char
f - float
i - int
l - long
v - var
s - struct
p - pointer
pp - pointer to pointer
pf - function pointer

e.g.
vTemp would be a var.
psData would be a pointer to a user defined structure
panDisplay would be a PANEL
vecTemp is a VECTOR
pvecTemp is a VECTOR*

Global variables always get a module prefix consisting of 3-10 capital letters.
<unit>_xxx: global variable which may be accessed by other units (should be avoided)
<unit>__xxx: global variable which is only used in the module wher eit was defined.

e.g.
LIST__vNumEntries: global var of the module 'LIST'. Not to be used outside the LIST module.
LIST_vReady: project global var defined int he module 'LIST'.
iParameters: local int variable. This naming may also be used for struct elements.

Function can either be global as well as local. They follow pretty much the scheme for variables above:
<unit>_xxx: interface function to other units
<unit>__xxx: module internal function

e.g.
LIST_getEntries(): interface function ready for use in other modules
LIST__process(): some internal function which must not be used in other modules

Core variable/function names (resembled by 'xxx' in the rules):
Are always CamelCase.

e.g.
vCamelCase
CAMEL_camelCaseFunction()
CAMEL__psCasedCamelCase


Example from my side: http://firoball.de/stuff/toolbox_manual/list_8h.html

If you like it, feel free to use, otherwise: no problem.

If there is more interest in this, I can also sum up some of my core rules for writing readable code.

My Code is modular, this means syntax is not so important as everything is exchanged via functions.
So you would end up having some template subfolder with all my crap inside and simply use the provided interface functions.

But at the moment I'm not set for the team anyway, as I cannot guarantee free time until march.
So maybe instead it should be discussed which code parts are already there from people able to work on the project right away.

As long as I don't see ANYTHING concrete from the gamedesign part, there's little use in discussing what we can build. But the naming conventions etc. is nice. I use my own conventions on personal projects but it doesn't differ that much.

It's possible to list the core modules we will need. There are thigns we need anyway, like:

[see below]

keep it coming. I'll transfer this list to the Brainstoring Etherpad right now...

edit: I won't add more units here. it just spams the thread. Placed everything in the Etherpad now.

-special effects module
-level controling/highscore control
-puzzle/riddle module

EDIT: tutorial module (or name it help module)

if it's not involved in the level controling module, then:

-saveing/loading module

Thank you for your guide lines and your doxygen toolbox.
Your naming conventions is not that strange - to be honest, it is very similar to my style. Well, try to survive without naming convention in a winapi based project... if you know what I mean.

About the modules.
Some modules like the menus, option screens and maybe key assignment (if you mean the visual aspect) depend on the style of the game.
Panels can slide in, fade in or simply appear.
Animation? It is undefined if we need 2D anims or full 3D.

I don't want to prototype a game prototype and throw the few hours per week away following a moving target.
We need to define game development related things, cut them into modules and assign them to the developers.

This is just my opinion and maybe there are different ideas about the next steps.

I fully agree on that.

With the module list I intended the following:

We don't know whether it's 2d (sprites) or 3d (models), but we do know we will need animations. So we should have a unit dealing with all animation stuff. The exact content is not known yet, as it depends on decisions which way to go.

But it is possible to split the code into parts for better overview.

I think that we should start with 3D stuff; we've got built-in collision detection that works fine with it. Creating models and animating them shouldn't be a problem; we can use placeholders at the beginning and buy and replace them later (if needed).

A view with ISOMETRIC flag set should deliver a nice 2D view of 3D stuff when setup correctly.

See Joozey's Key Perilous as example. It uses the ISOMETRIC flag to fake a 2.5d isoemtric landscape. Full 2d is just a different viewing angle.

==> It should be no problem to use 3d and all advantages the engine gives us this way without losing the possibility to have 2d look.

Sure, that's what I was thinking.

Don't be fooled, collision detection was the biggest bother in Key Perilous. My own 2D collsision detection is way more reliable . But you don't hear me complaining when doing 3D. Just stating the facts.

I've never had problems with c_move-based collision detection, but if we go the 2D route we'll give your system a try. Adding new features (powerups, etc) will require a significant amount of work if we use a 3rd party collision detection system.

I hope to learn something then about proper collision detection when we do 3D

I really hope that you'll learn something new

Hello programming team,

I have been voted the coordinator for art-team and just wanted to tell you that there are few operational things that are still in decision-making process.

The EtherPad that is up in Artists Corner was created for graphical aspects (will the game artwork be 2D/3D, art pipeline, graphical style...) as the opposite to programming questions like: collision system, movement codes, hotseat/multiplayer... but all these solutions does concern the entire team and was to be presented for evaluation, discussion & voting also to the programmers team. They are started at Artists Corner because they are, in their essence, graphical questions.

I have sent a mail to George to see what he thinks how all this should be managed. Should these things be global from beginning(some sort of entire-project-pad) or started in separated corners and then brought for global evaluation & voting.

I hope no one is offended by my actions since they were not meant to be offensive. Once George decides on how this thing is to be managed everything will be cleared out.

I'm currently developing the movement code and I have a question:
How many accessible "layers" do we have? I mean in SirCalamaris' (I forgot his name, sorry) demo there have been two when you consider a grid that affects the y-movement.

EDIT: I've made a quick (but IMO acceptable) movement prototype today from scratch. I've uploaded the file to the SkyDrive account, please test it and tell me what you think. Be aware that it is far from being perfect, finished and bug-free!

A Video.

I decided to give the girl (boy and girl look the same in the video) the ability to crawl. If that is not welcomed I will delete it of course.

Wah, I almost missed your edit: very cool video.

Demo is very cool as well. But I thought the one who can crawl is the boy, not the girl? cause the girl can switch gravity, but the other person can crawl...?
Speaking of switching gravity - the double jump works pretty much exactly how I imagined it: that's cool!
The rotation animation for the double jump could be a little quicker (I'm thinking of mario 64's triple jump).
The multiple-layer thing works really well.

Very good movement.
The layer switching however is not very clear - at least while watching the video. Not sure how it feels when playing.

Thank you for the replies!
Ok, I will make the rotation of the player faster, it is indeed too slow.

Yes, it is a problem to make the different layers distinguishable that I could not solve yet. We could increase the distance between them but if someone has a better idea then feel free to say it.

Try and place the camera a bit higher. We could also make the player models darker when they are away from the screen.

I dug out another game which uses layers. The player "jumps" when switching to another layer.

Check out this Guardian Heroes video: http://www.youtube.com/watch?v=55qO0DZKis0

Maybe it helps for an idea.

Thank you, Firo! That's an interesting idea.

Another idea: use a different camera perspective.

Then you can do the layer switch fluent, like shown in this video of a Turtles Beat em Up:

http://www.youtube.com/watch?v=FiUA561FFHM

I think simply adding a shadow to the characters should help a lot as well.

Dear team members, there is a new version with crate grid snapping, better camera and balloon crates on George's SkyDrive Account.

Hihi... this new version's actually really fun

http://www12.picfront.org/token/ZiAA/2010/02/26/1773870.jpg
(that shouldn't have happend... the balloon stayed there but should've kept going. It stopped, and so I pushed the other box onto it.)

Overall, I think this is getting quite close to what I'd like to see in the final game. I really miss the pulling of boxes though. For example, in this game you will never be able to get a box from layer1 onto layer2, without pulling. i don't think I like that, but we can of course limit the pulling to one of the two characters or something...

Thanks for your reply.
Yes, George already pointed out that bug for me, thanks anyway.

Pulling is an ability that I wanted to implement, too. Let's see what the team / leader says.

Looks spiffy Superku . If you can implement things not planned, totally fine by me! We're waiting for the artists anyway as far as I know .

Dear team members,
there is a new version on George's SkyDrive Account. Please test it and report bugs.

New features:
- Touch crates then hold [Ctrl] to pull them.
- Stack crates and move them altogether.
- Laser barriers that are not your friend (there is no restart at the moment, please use the gamestudio F2/F3 quicksave/-load function).
- New gravity code, both player and crate should not get stuck anymore.
- New crawl implementation.
- Switches that need a heavy weight (player/crate) to activate sliding doors.
- New collision system.

There will be a documentation about available actions (most of them are configurable) soon.


(Click to enlarge)

And a video

Regards,
Superku

Hot stuff Superku! I can't test now but the video looks great. And it will be even more way awesome if the camera will rotate with it.

I'll see if we can merge this demo with the interfaces soon!

Is it ok to use render-to-texture ?

PS: RedPhoenix contacted me and his input system and my movement code work well together.

Hi team members,

Last few weeks I was working on some music ideas for the game. I have 9 tracks uploaded on the SkyDrive and it would be great if you would download it and tell me what you think.

There is a new version with enemies, moving platforms, a restart function, new camera and plates that switch the layer of a crate touching it on George's SkyDrive account.

Hi there,

I've added my first version of the main menu prototype to skydrive/prototypes. It's integetrated in superkus movement prototype_0903 so that option selection and key_profile selection can be tested in a working level. I know that the menus look horrible by now (I'm certainly no artist!! ), so please try to ignore their appearence and focus on handling, structure and user-friendlyness. I hope you like it so far, of course it's far from being finished.
Features so far:
-Profiles selection menu
-Profile creation and auto loading function
-New game selection menu (relock feature is only a dummy ba now)
-Basic Game options that are saved with each profile individually
-key profiles selection (I decided to make the key assignment profiles independent from the game profile, I thought that's better and doesn't complicate things too much, as each game profile saves it's key profile selection)

Next to do steps:

-key assignment menu for editing key profiles
-advanced options
-autodetection for grafic options
-highscore menu

That is good news! I have tried to add your code to Superku's code but I am getting some errors. Could you please zip the entire folder and upload it? Thank you.

Ok I uploaded the code again, now containing a compiled exe. I also added a source folder, where you can find all needed files to port my code version to any other modul, and theres also a short description of what to do to get it running.

I hope this helps.

Thank you - great work! It was a misunderstanding; I was looking inside your folder on Skydrive and the good files were somewhere else .
A few notes:
- I'd like to see a "delete profile" button as well. Please make sure to add a confirmation box before performing the actual operation.
- If you try to create a new profile, you can't use the "cancel" button because inkey is active.
- How will the "auto" graphic detail work? I suggest that we should display a complex level behind the main menu panels, measure the frame rate for (let's say) 5-10 seconds, compute the average and then decide what to enable or disable.
- We also need a few resolutions for wide screen monitors: 1280x800, 1366x768, 1600x900 and 1920x1080 should be more than enough. We should also add what I call the "optimal" resolution, given by screen_size.x and screen_size.y - this one gives the best video quality for any monitor.
- I'm not sure how the "key assignments" section will work, but I think that it should display the actual keys, not the profile names, so that the player can remember them or change them.
Once again, you have done a great job; I appreciate it. Oh, and your programmer's graphics look much better than mine

I finally managed to check out your menus modul and it's great, very functional & efficient I like the game-levels map screen- that's a good idea.

Once we start with game visual-prototype development there will be a need for 4 more things: anti-aliasing(0-9), shaders(on/off), post-processing effects(on/off) & invert-mouse(on/off).
...maybe we should also make a water effect to be optional, or at least with higher/lower bmap resolution?

Some of these might be too technical for the average, casual game player, so maybe we should incorporate them in the "graphic detail" options, without giving the player direct access to them.

Add "Advanced graphic options" or so.

@RedPhoenix

I seen your work on the menu and I must say I'm impressed
I would also like to suggest adding program solution for sound effects and menu music. I could upload temp music that you can use for the menu and temp sound effects for all clicks. Once the menu is visually completed by the guys from the Art team i could upload adequate music and sound effects.

Keep up the good work

That's a good idea indeed, Dimme!

Hi guys,

I uploaded some music files and click sounds on SkyDrive so you can check it out and tell me what you think.
Also I uploaded temporary Menu music file. Hope you going to like it.

Best regards,

Dimme

Hi guys,

I finished the next version of the main menu code and uploaded it, it contains now delete buttons for the profiles, full working key assignment and advanced grafics and sound menu.
Important note: The advanced grafics menu is opened by clicking to the advanced game options button by now. This will be changed soon. Later the advanced options menu will be opened when choosing the advanced tag in the grafics combo box, and the advanced game options menu will be acessable correctly.

I also included dimmes music and click sounds into the menu code.
For testing music ingame you can add some .wav files to the music subfolder. They will (hopefully) automatically loaded and repeated randomly when choosing a new game.

What is still missing:
-Highscores screen
-advanced game options (mouse settings scrolling, camera etc.)
-auto grafics setting and effects of the grafics settings low average high

Greetings
redphoenix

Great job, Martin! I liked how the menu asks for a new player / profile name automatically when the game is run for the very first time. I also liked the advanced graphics options page.

A few ideas:
- The "OK" button from the "New Profile" window isn't really needed; type in your name, press Enter and you should be done. I liked how you can "Cancel" even if the player has started to type in his / her profile name.
- The existing player profiles should also be listed in the "redefine keys" section of the menu. Right now, you have to create the same profile again if you want to redefine the keys.

I appreciate your hard work. Pavle and I are bouncing back and forth the game design / story document these days; each one of us has written a doc and now we are taking the best ideas from each one, creating what Pavle has named a "superdoc"

Keep us updated on the progress, please

We'll post the doc as soon as it is finished (in 1-2 days).

Dear friends,
there is a new gameplay prototype on George's Windows Live account, please test it carefully. The crates have a different code (again...) that does not use "GLIDE" anymore, however they should not get stuck anymore, please tell me if you can push them through narrow passages and the like.
What's new?
The player automatically grabs ledges in mid-air when you push left/right, then press up/down to move on.
There are explosive crates (they don't cause damage, yet) that get activated by pushing/ pulling them.
The Sister was supposed to be able to fly upwards, so I implemented a very basic grapnel attached to a chain (for now you have to use your imagination) that you activate by pressing [Enter]. If you hold down left/right before you start it, you can pull crates towards you. Good/ bad idea?

I have just tryed your new prototype & it plays great

I love the ledge grabbing & entities that explode when pushed/pulled are a great asset. They can add much to the element of surprise if hidden among normal entities.

I must admit I was not really that excited about the chain thing, but, when I changed COLOR_WHITE from your script to NULL it does seemed more interesting: maybe it can be a sort of gluey blob with a string and when she throws it up in the air it can stick to the surface with some sort of “blupm” sound

Thanks Ganderoleg for your response. The chain is still early WIP and it can become anything you can imagine but I'm not sure if I understood you correctly about what you'd like it to be. Have you tried to pull crates across a bigger distance/ an abyss using the chain, f.i. to kill enemies?

Hello Superku,

I also tried your new prototype and think the grappling hook and ledge grab are two great new additions. I wonder if adding the mouse would make controlling the grappling hook or other abilities easier. As it is now the right hand only controls ducking and grappling hook. Maybe the mouse cursor position could be a "target" for the grappling hook and a left click could fire it. I'm thinking down the road, a right click of the mouse could bring up a local menu by the cursor with a list of abilities to select from (superjump, invisibility, superstrength, etc). A simple left click over the desired ability in the list would ready it, and subsequent left clicks would use that ability. What do you think?

No, I didn't realize it can go sideways. I just pulled a box with it & it's great

It would be cool, though, if the chain wouldn't go up straightaway but perhaps wait (maybe even a small pix like the ones you use to demonstrate the use of switches) until player presses the arrow key & count that press as a direction for chain (not as an intention to step left/right). It's a bit uncomfortable to press enter & arrow key at the same time (especially if player is, let's say, on the edge of abyss & has to pull the entity from the other side of the abyss.

But other then that it's very cool

Btw I just realized there is no more changing the camera angle when sister is changing the gravity Is there some reason why this is now excluded? It was a cool feature.

I'm glad you like it. The chain controls are awkward, so feel free to tell me your ideas about how to control them, SirCalamaris made a good point. I thought we could limit the chain to left/ right shooting for crates and only on special plates it would shoot up into the sky, e.g. to hold on to a branch in outdoor levels.



As George said this feature could make people dizzy when playing it will be an option in the main menu so everyone can turn it on or off. I for one don't like the rotating camera at all!

Yeah, that's a good idea about making the 180 turn to be optional I just had the impression that it has been excluded.

...I must admit I'm not so sure if the chain should be introduced into the game as a tool because it may disturb the main characters profile. Maybe we should consider making it to be a spell.

It has been agreed, it's not set in stone though, for potions(spells) to be distributed by the mouse only once per level. So in any given moment sister will be able to use only one spell per level (one in a sense that there is only one ability available per level not in a sense that she can use the spell only once, but that can also be the case for some spells). This decision was made in order to make key usage/controls more simple & to give clue to the player how specific puzzle can be solved (if given spell is super-jump player wont try to finish the level using super-strength )

But most important thing is that if chain is a tool, it's not her temporary magic ability anymore but it becomes her skill. If BJ drinks super-jump potion she is still just a teen girl that can jump higher, if BJ equips chain tool & know how to use it she is really Bloodrayne

Yes, you're right. It was supposed to become an item or a spell she'd get from the mouse.

Hello Felix,

The new code for the crates works fine - I couldn't find any bug in it yet.

The ledge pulling works great and will probably help our brothers hide from the evil BUM guards even better. The box pulling is great; crashing boxes into the guards' heads is a very enjoyable activity . We'll have to see how we can keep the user action keys to a minimum; the current implementation follows this goal, but might be confusing (the box pulling might be triggered accidentally). SirCamaris' idea (using the mouse) might be the best solution, after all. Another option would be to have a few (1...5) slots where we can drag the active superpower(s) from a bigger list - what do you think about this, guys? We could then select the active superpower by pressing the 1...5 keys (or have the proper power selected at all times, if we only use a slot).

One more thing: please make sure that each new ability can be switched on / off by setting a variable to 1 / 0. We don't want our heroes to be able to use all their powers at the beginning of the game

George, Is Untitled Platformer use the physic engine to pull the box ?

No, but it works great as it is - I wouldn't want to use the physics engine for this task.

Hi Superku, I downloaded your prototype level & I think it's great The chain feature is very cool.

What I wanted to ask you is if you could implement some sound effects into the next prototype level so that I can experiment with them.

I was thinking that you could make the following sound placeholders:

1.atmos.wav (main level theme similar to the solution from RedPhoenix's menu prototype)
2.moving_box.wav
3.elevator.wav
4.gravity_shift.wav
5.switch_players.wav (sound when shift is pressed & J's get switched)
6.chain.wav

...you can use the same sound for every placeholder, I will change them later, but please use these file names so that I know what file is for what sound.

Best regards

Thanks. No problem, I will upload a new version in approx. 1 week.

Hi friends,

Here are some codding suggestions:

When you're hanging from a ledge, you have to press up or down to rise or fall. I think it would be appropriate were the right and left keys to do this role, as in the rest of the movements are up and down keys to change game lane. In fact, when you're hanging in the background and you press down the button, the character also changes the lane. This would be avoidable with a little more code but I think that is not in harmony with the general way of moving.

On the other hand, when BJ was about to jump on an edge, if you get long and pressed to jump, she changes the force of gravity. I think you should have jumped in order to change the force of gravity.

Salud!

EDIT: there is a problem with the sister bounding box. She get stuck on one box tall holes. I modified 18th code line in 'movement.c' to 'var bbox_girl[6] = { -25,-25,-64,25,25,60 };' to solve this problem. Please, change it for future prototypes.

Hello,

I have realized that the main problem with shaders in my level seems to be the lowered blending of shadowmap. When shader is applied the model's shadowmap gets bleached out.

The best solution I've got is based on shadowmap replacement that depends on shaders being active or inactive. If shaders are OFF, the model uses the default shadowmap & if shaders are ON, the model uses modified shadowmap (higher saturation & lower lightness).

The problem is that we will have about 100 levels with, let's say, at least 300 shadowmaps. That's one BIG function It would be great if the shadomap assignment could be, somehow, automated.

This is my primitive code solution:



This solution works but it's very far from being elegant so it would be great if someone could look into this & maybe come up with some suggestions or, even better, better solution

I don't think that you have to have a shadowmap replacement.
I think it should be possible to tweak the shader's lighting part so that you could configure the shadowmaps contrast and strength. If it can wait one week (I won't have Pc access the next week) I could look into it and build in some tweakable entity skill for the shader's shadowmap strength.

Your right, it would save lot of time & code-space if this could be accomplished through the shader itself. I, unfortunately, have no idea on how to do this, the replacement thing was my best shot

It can, of course, wait for as long as it has to. Once shader is tweaked, each level can be shadered-up in about 30 minutes.

Thanx for looking into this problem

Hi friends,

sorry but i have been very busy last week and it will be same for another week.

A little advance:



Salud!

I've been in contact with Pavle - he has told me about your progress

Hello team,

I have uploaded the gameplay video for chapter 3, level 6 to SkyDrive. I decided to change a bit my level finishing/presentation process and, before I finalize the level geometry, textures & lights, I will first deliver the gameplay video in order for us all to validate it & for programing team to see if all aspects of gameplay can be coded or they should be changed.


The gameplay for this level is based on three things:

1.Player can use specific magic potion only once per level (player can use multiple potions per level but every potion can be used once per level).
2.Player has an >illusion< potion that he gained in the earlier level of this chapter (chapter 3, level 5)
3.Player must pick every bonus item in the level in order to finish it.


What the currant version of the level's gameplay demand in terms of code:

1.Doors that can be opened/closed without the need to stand on the switch.
2.Bonus item code solution (& visual).
3.Bonus system that takes into account the number of bonus items player has picked up, preventing the player from finishing the level unless all bonus items are taken.
4.Enemy awareness code solution that would enable the enemy to spot player if he is at the certain distance from him & to go after the player. Same routine should be applied if enemy sees the player's projection (illusion potion). Enemy should not react if player is at reasonable distance behind him or if player is over his head (gravity switch).
5.Code that would lower the basket of food to the cage (the movement itself can be animated, not coded, if that is easier).
6.Code that would make monster go into his cage at the moment that his food is in it (the movement itself can be animated, not coded, if that is easier).
7.Code solution that would not allow finishing of the level unless both BJ & LJ are present near the exit.
+
8.Code solution for >Illusion potion<. The spell creates the visual projection identical to the caster (Big J) three feet downwards/upwards. BJ shouldn’t be able to move while spell is active. The most difficult part will be, I guess, coding of the place where illusion should appear because it should take into account the first available floor (ground) beneath or above the sister model.

I believe that this is everything that needs to be coded for this level. The level can have more bonus items that can be spread across & some of them could even be hidden.

All suggestions are welcome

I can take care of these; I'll start with the first 3 things on the list. If one of the other programmers wants to get involved, please make sure to choose your tasks and post a message here; this way, I won't duplicate your work.

I completely forgot to add >Illusion Spell< in wanted programing solutions for level 6.

I updated the list with No.8

Hello guys!

I've uploaded an improved movement code to George's SkyDrive Account.
What's new?

• A new control scheme: You can play the whole game with the arrow keys, a jump button (space) and a context sensitive button - that's [A](ction) for the moment. A panel shows the current action that can be performed by pressing the Action key. Spells will be activated this way, too.
• You climb ledges automatically what makes the movement more fluid. You don't have to press a key anymore to go into crawl mode (boy only), just go near a crack (the model or ("None") block has to have FLAG1 set) and he will crawl automatically.
• Enemies that detect and follow the player ("enemy_follow").
• Imagine you have a special enemy in your level. When you have a key and Attach it in the enemy's (!!) Properties panel, it will only appear when the bad guy is dead.

Please try the example level and tell me what you think! The "goal" is to leave the room through the door on the very right with both players.

I tried it & I'm very impressed with how the game mechanics are now much more fluid Everything is much faster & more compact. Great work

I don't know if you are o.k. with doing also the spell system (?), there are some changes in the concept. Few days ago George & I talked about a ways to improve the level's visuals and came to the idea of making the spell potions to be objects scattered across the levels. They will be similar to the bonus items that are now present in the later chapter 3 levels and, depending from the spell system that we all agree upon, they could be placed in the specific order or just randomly positioned across the level. If we go for the magic-inventory system then order won't matter but if we all decide to have BJ carry one spell at one time (until it's used) then order of potions across the level would be much more important.

Also the Gravity Change that is now triggered with space will be just another spell potion that needs to be picked up in the level. We could keep the trigger mechanics (second space while Sister is in the air) but it should be possible to do this only after picking up the Gravity Change potion and, as it should be with all other potions, only ones (or unlimited times in limited time-frame) with one potion, twice if player picks up two potions, three time if he picks up three and so on.

..just to mention that this concept does not exclude the mouse-wizard factor: Bj will still receive new types of spells from the mouse around level 5 of every new chapter but the spells themselves will be bottled & scattered across levels

Btw, did you gave up on the camera angle change during the gravity switching? ..or will this still be available through the game menu?

Thank you for the information and thanks for testing!

I like the idea of the gravity-potion but I think then we should drop the double space key activation to stay with a continuous control scheme.

An idea: When you already have a potion and stand next to a different kind of potion, the context sensitive button will change to [Switch potions] and the old potion will be dropped at this position so it can be picked up later on.



Somehow it is still there but the controls won't work right at the moment. It will be controllable by a variable (camera_mode).

It was a real pleasure to test it I would like to switch my levels to this movement code if you think that everything will work o.k.

Btw that idea about potions swap is great! We will be able to skip on the complicated magic-inventory thing & still have a working system without the need to have any specific order of potion level-placement. All we will need is a spell icon of the picked-up potion in the corner of the screen & that's all.

..and yeah, it may be better to drop double space activation & unify all spell-usage to one key.

Just tested the new movement code and it works great! The wall climbing is much smoother now and feels more natural.
On a side note, I think that we have to lower the movement speed while the player is using the stairs; what do you guys think?

I agree, the stairs-climbing speed could be a bit lowered.
..and just one more thing that I failed to notice earlier, maybe the context sensitive button shouldn't be the A key since in menu we are offering the possibility to use WASD instead of arrow keys.

I'd say that even the descending speed should be lowered. And you are right, the shift key(s) would work better for that

They key will (should) be configurable in the menu (my code uses the keys(ip_activate) instruction, not key_a), it's just an early implementation.

Thank you. Please make sure to decrease the stair climbing / descending speed by 50% (or so).

Hello team,

I've uploaded the level to SkyDrive (Ganderoleg C3 NonCoded V1) that contains all objects (from chapter 3) that are in need of code-solutions so maybe you can take a look. I didn't place in the level 'shared' objects (doors, elevators...) but I added them in the included document to show how they should be modified.

Included document contains detailed explanations of how the objects should function & what should be modified in the existing code solutions. I also added the SFX placement-explanations that Ivan & me agreed upon. The needed enemy routines are not included in this doc.

Btw, different objects in level are separated with different texture-patterns, and they are placed in the same order as they are explained in the document.

@Superku
I just wanted to point out one thing that is potentially dangerous when it comes to gameplay: when sister is changing gravity she falls back if no ground is to be found but while falling she can move in the air. This shouldn't happen because the player can just change gravity, wait until sister starts to fall & move to, in normal conditions, unreachable parts of the level. I think we should make the entire gravity switching process to be fixed, with no possibility to move while ascending or descending from the air.

You are right, I will fix that.

Thanx, that would be great

Did you have time to take a look into my non-coded level? George said that he will take on some of the 'non-shared' entities, objects that are not originally coded by you.

It would be great if you would consider modifying 'shared' entities (doors, switches...) because I believe that it wouldn't be right for someone else to re-write/change your code since they use your actions. I haven't placed them in the non-coded level because they are already in your movement-levels but you can find all necessary explanations in the 'Chapter3NeededCodeSolutions.doc'. Mostly they only require adding of sound effects but there are some minor modifications/expansions that should be made in order for them to fit gameplay needs better.

Did you check the Level 8 V2 with the implemented background? Do you think that it looks o.k.?

Looks great! I cannot seem to find the Chapter3NeededCodeSolutions.doc, where is it supposed to be? Besides, I am not able to open *.doc files, could you please provide it as a simple text file? Thank you!

Great I'm glad you like the new background.

I uploaded the level with entities that needs code solutions (Ganderoleg C3 NonCoded V1) to SkyDrive under 'Other' section. The document is included with the zip, but I will upload it separately in txt format under the same section.

Thanks!

I've uploaded an improved movement code, esp. the stair climbing was horrible which should be smooth now!
If you have stairs, place a block in WED below them with a "none"-texture attached and check Flag3. (Check Flag1 to activate the boy's crouching mode automatically). See my example level!


I thought we could use a single key, the context sensitive button, to pull crates, activate switches, switch players and to use potions. The problem is, you should always be able to take the reverse-gravity-potion and to switch players. I think we just should add another key for potions only, then we have three keys (jump, context, potion).
What do you think?

I just tested the new movement code and it's great

The stairs ascent & descent is much smoother and, if I'm not mistaking, the gravity change can be accomplished only if there is a ground at reasonable height above the player?

I was thinking about the potion switch idea and, unfortunately, I believe that we should abandon it because there are situations where this system will just not work. Take this situation as a mild example: You need to pick up illusion potion from the ceiling so you use gravity potion to get to the ceiling, but in order for you to come down from the ceiling you need another gravity potion. So the ceiling is completely useless because once you are on the ceiling you can't carry anything else from the ceiling because you need to take gravity potion in order to come down.

We should look into having some sort of spell inventory or similar thing in the game. My favorite concept is the one from Clive Barker's Undying:
http://www.filefront.com/17346826/Undying_SpellInventory.wmv
..we could have right-mouse-button-click-and-hold in order to open spell inventory & mouse-move (while holding) in order to browse through the spell inventory, but I'm not against any other concept.

"he gravity change can be accomplished only if there is a ground at reasonable height above the player?"

Correct!

"We should look into having some sort of spell inventory or similar thing in the game."

Thanks for the clip, the system looks nice. We could have a three(?)-slot-inventory at the top of the screen, too. When you need to switch to a different potion, you could hold down the potion key for a second and select a different one with the left/ right keys. I think we should not use the mouse as a control input.

What does George think?

O.k. I agree with no-mouse direction. I haven't talked to George about the potion inventory system yet but I believe that he would also be against using the mouse.

But I'm not sure if we should limit the inventory to three potions, maybe we should consider something similar to Star Wars Jedi Academy:
http://www.filefront.com/17348410/StarWarsJediAcademy_ForceInventory.wmv

Your idea about holding the potion key and switching potions with arrow keys is not bad but maybe we could make things even more simple. How about if pressing the potion key (let's say P) would switch/browse through the potion inventory but also display the potion information on the action panel. So you browse with P, but if you press A while holding P you use the potion.

Pressing P would have to override any action info on action panel (if any possible, near action is already being displayed) and, if not pressed (or if P & A are pressed and potion is used), everything should return to normal (possible, near action should continue to be displayed).

What do you think?

A cool inventory system is like in Legend of Mana on SNES.
Or in the last ZElda Twilight Princess , a circular inventory ;
made in Mass Efect in some sort also : easy to pick with mouse and more fast to use !
Zelda inventory

Mass Effect combat inventory

Just ideas

Yeah, they are very good (I like Mass Effect inventory better ) but ,now that I look back, I think I remember that we agreed to leave out the mouse when discussing the game controls few months ago.

The potion roll may be a better solution when compared to the potion circle because it takes less design effort, only three potions could be displayed at the same time (with circle the whole inventory is being displayed) & it can always be visible on the HUD since it takes less room. But, on the other hand, the circle can be much more attractive & dynamic feature.

In Shining Wisdom they used a very simple but yet effective inventory.

You had three slots and were able to put there what you wanted. Weapon, spell, item, special skill... no matter what.

Does not work for quick gameplay (shooter) as putting stuff to the inventory will have to work via menues, but for adventure games where you don't need to switch items all the time it worked great.

I agree its asks lot more effort.
If it is only three items, yes perhaps avoid coding the circle menu.

The idea of slots is heavy used in top notch iphone games also like Dungeon Hunter and others. good idea also.
Another idea is to assign items inventory to keys, like in Twilight Princess you can have the keys displayed on right upper corner with the item on top of key letter !




The most important is to make slots, keys or potions picture really attractive :
For exampel in Super Mario Galaxy all HUD indication are very attractive to watch , a real pleasure caus of very good design :



Well it's not the main important feature , but polishing it , will bring up the game , caus you see HUD all along the game.

I don't have anything against using the mouse, as long as it doesn't break the gameplay. Imagine a player controlling one of our characters using the keyboard, and then having to grab the mouse in order to quickly use a potion that will help it avoid / trap / destroy an enemy. My goal is to make sure that the gameplay isn't fragmented, even if this means to make the player use the mouse at all times or make sure that the potions are only used in areas that aren't dangerous for the players.

I've made a quick sketch today. This is one version of how the basic HUD-items position could look like:



We would have the action panel in the upper part of the screen, exit-key indicator (key would appear when collected), number of currently collected bonus items, currently held object & potion inventory (displaying one currently selected potion, one previous & one following potion in the inventory).

Player would carry only one object at the time & switch it with other object in the level with action button. Potion button would switch through 2 potions in the second level & 10 potions at the last level, always displaying only up to 3 potions in the HUD.

How does this concept seems?

We could use the action & potion button pressed together as a trigger for potion consumption or use separate button for consumption?

I've tried a mouse-only concept and I think it works quite nicely.
It may take you a minute or 2 to get used to this different control scheme, but I like it.



By moving the mouse you move the knob and thus the player. When you hold down the right mouse button, the potions and the player-switch-icon appear. Move the knob next to one item and release the right mouse button to activate it.
Currently, only the player switch and the red potion ( = gravity change) are usable.

I've uploaded the new movement prototype to George's SkyDrive account, as usual.
Please tell me what you think, what you like and dislike!

EDIT: There's a new problem: For now, it's impossible to pull crates because you would have to use another key. Anybody got an idea?

Maybe we can keep the keys for movement, pulling, etc and just click the potion buttons?

Did you try the mouse control scheme yet?

"Maybe we can keep the keys for movement, pulling, etc and just click the potion buttons?"

To be honest, I would hate to have to grab the mouse just to select/ activate potions when I play the rest of the game with the keyboard, or have I misunderstood your idea ?
The knob could be moved by cursor keys (/up/down/...), too, to select a potion.

I tried it & it's different & very interesting

I can't say at this point if I'm for mouse-only concept or not, but if we decide to go for it there is just one thing I found to be problematic: the movement slowdowns/gradual stopping. It would be much better if the players movement & knob could be much faster in status switching. If I move mouse to the right the player should start moving to the right & the knob should be instantly all the way to the right, and if I move mouse to the left from that position, the player should instantly stop and the knob should instantly be at the middle of the circle.

The thing is that I was more focused on the position of the knob & how to stop the player then on whats going on in the game. The movement of the knob, in my opinion, should be much more similar to the pressing of the buttons: instant & controllable without looking at it.

Edit// Maybe the knob thing could be replaced with sort of flashing arrows: when mouse is moved to the right the right arrow on the circle is lit?

Edit//Edit// You actually have something similar to that already: when I hold right mouse button, move the knob all the way to the right and then release the right button, the knob instantly goes to the middle of the circle.

Another idea i found on a indie game on PC !

You press mouse button anywhere on screen, it becomes start position, form here if you move mouse to the right , the character moves to the right etc ...
if you release the mouse, the character finishes it's running by decelerating and stay in place doing nothing.
Depending on how far you move the mouse from the start position, the characters walk or run.
It's another similar but lot more intuitive way then having to really target the virtual joystick with the mouse, that will break a lot the fun and fluid gameplay of the game !!!

Just my personnal point of view !

Thanks for testing!

"You actually have something similar to that already: when I hold right mouse button, move the knob all the way to the right and then release the right button, the knob instantly goes to the middle of the circle."

Yes, that happens on purpose. If it stayed right and you released the button (to select a potion), the player would instantly run to the right and may run into a trap.

@ratchet: I've implemented such a control scheme a year ago in my game but I found it somehow confusing.



I've uploaded a new version, Movement0510_b.zip, with improved mouse control. Now it behaves like normal buttons, don't concentrate on the knob, just move the mouse and let it flow!
The player (for now only the boy) is now able to push and pull crates with the mouse, too. Just hold down the right mouse button when a special panel appears (you will know which I am talking about when you try it yourself).

Regards

This version is much, much better but... I still feel like there is too much freedom while moving the mouse.

It's been a real long time since I played anything with the classic joystick (it could be even from days of Amiga 500) but I remember that the joystick used to return to the default position when you release the handle? You could try, if you have time, to make the knob 'fall' into up, down, left ,right & middle positions and not really make the whole trip to them. I'm not sure if I explained it right.

But this is my impression, other players could have the opposite opinion so don't take this as a critic

Thanks again for testing, but I'm not sure if I understood what you are trying to tell me!

"too much freedom [...] not really make the whole trip to them"

I've made it this way that you can actually stop the player. If you run left and move the mouse right without a dead space, you would never be able to stop the player. Do you have a better idea to make the player stop (if the player wishes to do so, of course)?
The control experience naturally depends heavily on the mouse sensitivity, so the feeling of the "dead space" could be adjusted in-game in the options panel.

You’re right, the dead-space should stay, that's not the problem. The thing is that there are too many in-between-steps available, if you position the knob just a little to the left or right you can even make player run in slow motion

I believe that you should maybe try it like this: if the distance from left to right is 100 points, you should make 0-10 to be used for left, 10-90 to be used for stop & 90-100 to be used for right. The reason for this in my opinion is that it's very easy to make player go right, you just go all the way to the right with your mouse, but it's very tricky to make the player stop because you need to target almost perfect middle of the circle.

"The thing is that there are too many in-between-steps available, if you position the knob just a little to the left or right you can even make player run in slow motion"

No, that is not possible anymore. That's why I said the control behaves more like normal buttons, now - it's only full speed or still standing. But you're right, it was like that in the first mouse movement version.

Do you think that it's bad to have some kind of analogue movement like you'd have when playing a console game with a gamepad?
I've just wanted to implement it again so you can walk slowly if you want to. Bad idea?



EDIT: And again, there's a new movement prototype on SkyDrive! It's an unusual approach but please give it a try!
I've tested it for more than 20minutes and it really gets to feel good (for me), not only the movement itself, but switching players, selecting and using potions, too.
The inner 50% of the circle is a dead zone, the rest is slow walking up to fast running.
Try to push the crate to the key that appears when you kill the enemy_chase.

If it feels weird to change layers in reversed gravity mode, open main.c and set
var ip_y_reverse = 0;
to true (/ 1).

I can't believe it: I've downloaded the new version (Movement0510_b) and unziped it but for some reason I seemed to have opened main.c from the earlier script (Movement0510)

You are right, the mouse coordination is now o.k. Sorry, I don't know how I could have opened the wrong script.

I believe that simpler solution is a better solution, I wouldn't over-complicate features with slow motion features.

Btw, what about the design: do you think that we should keep the circle/knob position as it is now or move it at the middle of the screen & up or down? Are the circle/knob position dependent, can I redesign & move them without damaging the functionality?

No problem.

"Btw, what about the design: do you think that we should keep the circle/knob position as it is now or move it at the middle of the screen & up or down? Are the circle/knob position dependent, can I redesign & move them without damaging the functionality?"

Did you test Movement0510_b or Movement0510_c this time?

You are too fast

I tried it but.. I don't know. It seems like they’re in some sort of bubble.
It doesn't look so bad in your prototype level since it's mainly geometrical but it looks a bit off in the actual game level:



Strange looking player.

Yes I know it's ugly!
But what's about the movement/ the controls?

I can't really say that I see bigger control differences between Movement0510_b & Movement0510_c but if I would have to choose I'd say that the _c seems to be somehow smoother.

Oh that is sad, I thought it feels 10times better!

Nevertheless, I've uploaded a (hopefully) visual more appealing version (Movement0510_d) to the well known account.



The arrow's length depends on the movement speed.

BTW: People with only one or an injured hand can play our game this way, too!

Tried it but it still looks very strange to me With the arrows I feel like someone is pointing out the obvious to me without any reason to do so.

I believe that there shouldn't be any artificial, direct visual attachments associated with the players in order to keep things in semi-realistic concept. The arrows could work, however, in a situation where the player needs to control artificial objects, maybe the arrows could be made active while pushing/pulling objects, or in a situation where the non-player model is being controlled (if we should have Golem or robot control in some level). But, as for me, in that situations I would still prefer the circle with the knob to appear around the model (Golem or robot) instead of arrows.

In any case, I do find that well positioned, nicely designed & animated circle-like object would be much better then objects directly attached with the player models.

...
But when talking about the mouse-only movement concept I believe we should also consider what would be a better selling point, since we are making a game that should have commercial potential once it's finished. It's true that from visual point of view having a cool-looking, animated round object with a discreet light-effects as a movement-control object is great & very interesting for viewers but is it better from the actual movement-control point of view? We mustn’t forget that pc game consumers are use to having a classic control systems depending from the game type. We should be very careful not to lose customers because of un-ortodox movement control system.

I'm not, nor have ever been a social researcher & I have no idea what market effect can this control-switch have on our project but I know that, in my experience, unusual things always go unusually up or unusually down We just need to, somehow, calculate what's most probable outcome.

Perhaps don't try to go in the Iphone way, caus such control
is similar.Why not staying with keys ?
Right, Left, Space to Jump, C to shoot etc ...
And let the user redefine the keys if needed !

I'm not sure you will be precise with mouse, for platform style.
Caus platform works lot more with keys, more natural for that type of game. A good way, submit the two methods to players and ask them the better way, i think the majority will vote simple Keys ?

Well juts my opinion !

"Why not staying with keys?"
You're right, some (/many?) people will probably prefer the normal keyboard controls, but I did not intend to remove this type of control, it's just a variable that you can change in the main script (or later in the options panel).
Either use the mouse movement or stay with keyboard controls (and configure them yourself).

While the mouse control seems to be pretty innovative, I'm not sure if it is conform with the initial statement to make a game for kids.

I just think classic keys feel more natural, but I wasn't able to try the mouse movement, so maybe I'm all wrong here.

Mouse/keyboard option in the game menu is not a bad idea but I believe that, in this case, both versions should have the same HUD-movement-circle design. The only visual difference could be that keyboard mode would be without the knob & mouse mode would be with the knob. Here is the quick sketch:



The problem is that in the mouse mode right-button solves the spell switch & consumption in one quick swoop, while in keyboard mode this will be very difficult: buttonX (holding) for potions to appear, buttonY to switch through & buttonZ to use? Or we could have buttonX (holding) for potions to appear, buttonY to switch through & when buttonX is released the potion is used or action is canceled if you switch to cancel slot (if switch player is South, cancel could be placed on North)?

I'm not pretty sure what's to do/ code next, I remember some points by Ganderoleg about improved AI (enemies that look for certain events and the like) but I forget more than I remember. Thus I've created a (public) to-do-list for our project which can be found here:
http://www.toodledo.com/views/public.php?id=td4cf6fbf111862

Please add everything to the list what needs to be in the game, the list is not restricted to code suggestions.

(PM me for account information.)

Great idea:) I will send you pm, I'm not sure how Toodledo works.
...

O.k. it's all figured out
I added few things that I remembered first, but I will go over all the levels tomorrow & see if there are some AI aspects I left behind

Thank you, that todo list is a good idea! I have posted a comment on the AI section, as well as added a new item (the sky system).

I've updated the to-do list with completed tasks and 1-2 questions.

There is a new movement prototype on the SkyDrive account. There are some changes and many new things (see to-do list), including a spell selection with keyboard controls, some spells and smarter enemies.

It's great, I tried it & everything seems to be functioning very smoothly I love the new Brother's ability to crawl through spaces that are in different lane

Few problematic things:
-Sister should be able to use the Gravity & Illusion spell while brother should be able to use only Invisibility.
-Illusion Spell is a part of the gameplay in levels 5 & 8, and, unfortunately, in both cases Sister will not be able to physically reach the needed point I believe that you should consider the original Illusion concept (The spell creates the visual projection identical to the caster three feet downwards or upwards. BJ shouldn’t be able to move while spell is active) or, if you think that some other solution would be better in terms of gameplay (maybe 'placing' the illusion-body in specific distance from Sister or controlling the illusion-body (moving it) until you start second part of the spell) try that one.
-The alerting (investigating) is a part of gameplay in levels 3 & 6, in level 3 guard should go from the upper room down to the four pipes when they get blocked & start emitting tick black smoke & in level 6 monster should enter the cage when food is lowered. In both cases characters should stay in those locations with only one difference, guard should react if players pass him by but monster should just eat the food no matter what happens around it

I added some of the remaining (non-entity oriented) needed programming solutions to Toodledo & one more Smarter Enemies addition.

Hi guys,

It’s been a while since I posted anything. I am done with recording and implementing the SFX files needed for the Pavle and Martin’s non-coded level.
I have uploaded the ZIP with level on the SkyDrive in the Music section.
Also first Theme for the chapter 3 is finished and I’m currently working on the Menu theme.
Martin’s program solutions are great, i stumbled only upon two minor things.
Some sounds are not being played (cannonball hit, pick up object) and the second thing is that sound for Digger Stem Stop are being distorted when it’s played (compare file from the folder with sound you hear in the game).
Sound for the Cannonball hit and Cannonball push are being temporarily adjusted by Pavle.
I hope you will like how everything sounds but any further suggestion is welcome. Also there is a separate Txt file for each sound that controls sounds volume in case someone would like to experiment.

Greetings,

Ivan

I will check the sound codes with the new sound files and adjust them to fit with them, so that everything will be played correctly. If everything turns out right, I canprobably upload a new version next week, it will also include the solutions for the missing points on the list. I'll try to integrate all codes into the latest version of the movement code. (This is the one from 05.12.10, correct?)

Thanks, I'm sure that you will be able to adjust them without any problem.
Pavle told me that he had some difficulties with integrating your scripts in Superk's new movement code (051210), so it would be great that you could make them work with latest level versions.
Also he told me that he will make an additional non-coded level which will include all of the still missing entities that requires sound effects (moving box, doors, telescopes...)
I forgot to mentioned but i had a problem with sound volume so i had to put very high volume numbers (2000,2500) to some sound effect, was the master volume lowered or is this a normal thing?
When i was working with Pavle on our projects sound max level was on 100.

Greetings

Hello Team members,

I'm nearly finished with the code solution list now and I have some last questions belonging how I should best integrate my code into the existing prototype:

1: Should I integrate the global use object system into superkus ability selection sytem? By now eg. pushing the cannonball is done by superkus code, the selection of player items is then disabled for the time the player is pulling or pushing an object. I could integrate the usage of other objects (cage, switch, basket etc.) into this system, advantage would be, that there will be only one control for activation, object usage and item selection. Disadvantage would be, that, whenever the player stands near a usable object, he won't be able to select a potion or switch the players.

@superku: if I integrate the system into your codes, I will just create another var similar to "pulling2" in the switch player function which will supress the potion selection whille it is set.

2: When working on the codes, I rearranged a lot of code, eg. I created a main.h including all definitions done in mvement.c and object.c so I had an overview over the skills used by other codes. I also integrated all extension scripts into existing script files. Would it be ok for you to overtake this version of the code? I used the newest code files I found on skydrive as basis.

3: When implementing the level changing system I realized that some levels have problems when run on the latest code version (taken from the level8_V3 prototype) Esp. level2 has a repeating error message (guess: shadeC or skysystem?) , where I didn't found the reason yet (I have no time to compare 9 versions of code to find their differences in each version). May be some of you can find the reasons for this error when testing the level changing.

4: I did some small changes (adjusting new actions to cannonball and digger etc.) to some levels with wed. I'll include a list of these changes so that Pavle can actualize the level versions.

I realized that the combination of all 9 existing levels takes nearly 300mb memory. So I won't be able to upload a complete prototype on skydrive. I will instead upload the complete code and all level wmb and wmp file, but no grafics and sound files.

Greetings
redphoenix

This is great news, I hope we will have completely functional chapter 3 levels soon

I'll focus my comments on things that are related to me or to the project in a global sort of way.

Concerning the first thing, I must admit that I'm not sure how this concept should be approached. I find the system where I can't access the potion/player switching menu when standing near the object that can be moved a bit distracting. If we expand this also to objects that can be picked up/used it could potentially be, in my opinion, a gameplay-killer

The error messages I get are all connected to the use of 'linked_door' action & are creating the 'Crash in sc mtlEvent_depth: SYS' error, I guess that this is Shade-C DOF related error because it does not occur when DOF is turned off. If your problems with level changing are Sky System related then they can be ignored because the system is going to be replaced with the new one that George is coding.

As for last thing, anything that should be changed in order to enhance the functionality of the level is o.k. with me

Hey team,

happy new year to everybody!

I uploaded the next version of the code solutions now to skydrive/prototypes (codesolutionsV2.zip I forgot the date, sorry). All points on the list are done in thi version although I'm not that satisfied with some solutions right now...

I included several lists with changes I made to levels and code. To run the prototype you have to include all grafical data and most model files to the folder, the file would have become to big, if I'd included them. Theoretically it's possible to walkthrough all 9 levels now, however I didn't know where to place the exits and therefore just placed them somewhere so it might not work in every level. You can also browse through the levels by redefining current_level or by setting collected_bonuses ingame to a high value and then entering the exit.

There are still a lot of problems including some error messages when level switching and when using postprocessing, therefore it's disabled in this version. Esp. view entitys don't work for me when ppe is on.

@ganderoleg:
I'm very sorry but I didn't see that you uploaded a new version of level 2. So the old one (V2) is included in the prototype.
@superku:
I took the newest version of your script as basis. As I changed a lot of script files, it won't be easy to integrate the codes into another code version, but if your actual code version is not that different from version 05.12.10 you might integrate your new codes into this code version.

@dimme: The problem with the volume was related to the usage of 3d entity sound commands instead of snd_play. I corrected this for all sounds that are not really related to an object or that are only played when player is near the object at any case. But for the digger I had to use the entity sounds, so there the voulme (which also define the sound distance) has to be high as the camera has always a certain distance to the level plain.

greetings
redphoenix

Great news & great work

I've downloaded the zip immediately & made a few tests I was, naturally, unable to tryout all of the levels with new scripts at this time but I've tested levels 1 through 3 & they all functioned very good

As for errors & similar issues I haven't found anything in first 3 levels that you haven't already mentioned in your readme file:

1.The cannonball does seems to be somewhat off because of the crate-hull around it, but once we change player placeholder-model with real player's models we could have few 'push' animations, for large, middle & small objects (with hands in upper, middle or downward position)?

2.In all of the three levels error message displaying 'Crash in switch_players: SYS' appeared when leaving the level.

3.When ppe's are enabled view entities aren't shown on the screen, but the error message 'Crash in sc_mtlEvent_depth: SYS' appears only if DOF is running, otherwise no error message appears (no error with HDR, desaturate & colorshift).

I'll give all remaining levels a try & see if maybe I can also assist in some small way, by creating additional code that will restrict use of magic potions only on those potions that have been picked up, add m_potion action to all magic potion bottles in the level & maybe try to somehow fix that Shade-C DOF depth error.

Hi guys,

Happy new year to all

@RedPhoenix

It's a great job you did and thanks for the explanations.

About the implemented sounds, after talking with Pavle we agreed not to use some sound files:

Digger_steam a_d
cannonball_falling

I was not planing for the cannnonball_push to be that short so i will try to recreated in another way.

About the missing sounds, we need a few:

Switch players
Push crate
Enemy and monsters random sounds (Mumbling, breathing, getting hit...)
Sounds related to game play (player getting caught, level restart)

That's all i can think of in this moment.

Greetings,

Ivan

Ok, I'll remove those files from the code.
About cannonball push: The point is, when pushing the ball this can be a very short or a very long process. But it sounded strange when a long sound was played and the player only tipped the cannonball.

@ganderoleg: I think we should wait with the final cannonball moving process until we have the final player models. Up to now it's at least possible to work with the cannonball more or less.