Community
General and Everything Else => Everything-Else => Topic started by: MusicallyInspired on March 02, 2015, 11:47:01 AM
-
Anybody hear about this? Starting in April, developers have two weeks to construct an adventure game from scratch and everybody votes on them in the end. There is no specific engine required so SCI games count! You can write your story and game design documents any time but the actual programming, graphics, other resource assets, etc must not start development until the two-week period. Some of you should enter, there's a lot of talent here. SCI games can be easily bundled with DOSBox for play on any system, obviously.
http://jams.gamejolt.io/adventurejam
-
I am currently suffering from, what I hope to be, a temporary case of Brain Deaditis. A project at work has got me reaching so far outside of the box of my current programming abilities that I am currently unable to think through two lines of code at a time. I read this and thought, what kind of adventure game would I make and so far the little voice inside my head simply responds with "Uhhhhmmm" and then trails off.
So unless I suddenly have a stroke of lucidity I probably won't actually enter myself. I would however be more than willing to help out if anyone else out there has a great idea and is a little worried about actually getting it coded. I offer you my keyboard.
-
I'm seriously considering doing this. A bit concerned with the extremely compressed time frame, but I've got my basic plot together. I figure if I don't have the story completely fleshed out before the jam begins, I'm sunk.
This is a completely different approach than I'm used to. I'm more of a 'dive in head-first and see what happens' developer. I prefer it when things 'organically' evolve. Planning *everything* up-front without doing any coding is a bit daunting.
-
I'd say the Scott Murphy "seat-of-the-pants" design philosophy is still possible, just keep a smaller scope for story in mind.
-
Jam just started. I'm going to hijack this thread to track my progress. Wish me luck, I'm going to need it!
-
Good luck! I've got a big gig coming up so that's going to take all my time. I won't be able to participate like I had planned to. Are you using SCI?
-
Good luck! I'm excited to see what you come up with.
-
Are you using SCI?
Of course! I started my asset gathering last night. My plan is to get the basic framework of the game in place with as little development as possible up-front (placeholder views, sparse room pics, no title screen, stubs for narration & dialog, no sound effects/music). Once the game is fully playable, then I'll just use an iterative approach to improve it. That way I won't bite off more than I can chew on any one aspect and paint myself into a corner where completion is impossible.
-
Good luck to you Gumby. If you need any help with anything or a play tester, let me know. I would be glad to be of assistance.
-
Thanks Cloudee - I will definitely need some community help to get this ready to submit.
On another note, I'm better understanding the power of putting all objects that you can interact with as views instead of embedding them into the room pic. In my previous games, I would just draw the object into the pic (provided it was a static object) and then use control colors to determine if the ego is close enough to interact with it. It's so much easier to just make the object a view, then use the distanceTo() call between on the ego and the view to figure this out. Plus, then you don't have to worry about the dimensions of the object itself or where it is placed on the screen.
-
Experiencing if/then/else hell.
It seems to me that there is an opportunity here for a new tool. I'm thinking a tool that would take something like a state-table as input and would build out all the if/then/else logic skeleton for you.
-
Massive blocks of complex if/then/else logic is usually a code smell (http://en.wikipedia.org/wiki/Code_smell). There might be a way to refactor your code to avoid that kind of thing?
-
Yeah, I agree about the code-smell. I've put together a puzzle that requires 5 different elements and I find myself nesting if/else statements, checking boolean variables for their state so I can print an appropriate response (all around Said statements). It's just difficult trying to keep track of all the possible different scenarios.
-
I began working on pics and non-animated views today. Coming along nicely, I've completed nearly half of the first (maybe only) room a couple of views.
-
Do you think that a Sierra-like game written in Scratch 2 (the online version) would be suitable as an entry? I've been thinking about testing the boundaries of a visual programming tool like that & need something to kick start me in to trying it. Maybe this is an opportunity. Do you know if remakes are excluded? I'd be really keen to try building a 3d animated version of an old VIC 20 text adventure game from 1983 that most people won't be aware of. A couple years ago I decoded all its game data including the scripts & could in theory reproduce the same logic. The creativity bit would be rendering my imagination of the various rooms which are described as simply "I'm in a forest". I realise there are only 9 days left though. Why Scratch 2 and not the more powerful Snap? Well Scratch 2 is really popular at the moment with kids and educational institutions, so it might actually get some exposure. Snap seems to scare my kids for some reason. There is an offline version of Scratch 2 if an online entry isn't possible.
-
I think any engine is allowed. They even allow programming an engine from scratch, but you can't start that until the two-week period starts. I don't know about remakes. Ask on their forums.
-
Ok guys, I need a little help please. I've never run into this issue before and it seems like it should be a common problem. I've got a view that has a significant amount of depth to it (it's a bed that is positioned with the headboard 'nearer' the front-aspect of the room and the footboard towards the back of the room.
When I drop the view into the pic and navigate the ego around the bed, I don't want to be able to see the feet of the ego when they are walking behind the bed. For that matter, the ego is able to come too close to the bed from the 'back side' on the z axis. It looks like the
I've dealt with this problem in the past in a pic by just drawing control lines and preventing the ego from crossing them. However, the view needs to be movable so I don't think control lines are an option.
Wait, or maybe the issue is that the ego can go too far down on the y-axis and the bed should prevent that movement before the ego gets to that point. Either way, I've attached a screenshot to illustrate.
EDIT: Is this a priority color issue with the view? Maybe I just need to bump it up or down into a different band.
-
One thing you can do is make the collision rect of the bed larger. These are the brBottom, brTop, brLeft and brRight properties properties of a View. However for View and Prop, they are set automatically with the BaseSetter kernel. But Act's have an optional basesetter property that lets you override that. Have a look at the NormalBase instance in the main script. It's assigned to the ego's baseSetter property. So if you made your bed an Act, you might be able to use that.
Of course, that's a rectangle. Given the shape of your bed, you might want the edges to be kind of diagonal?
Perhaps a cleaner option is to create a block. If you notice, an Act (and therefore the ego) have a blocks property. You can add/remove blocks to the ego using observeBlocks and ignoreBlocks. These describe areas the actor can't go. There are classes Blk and Cage in feature.sc that show examples of blocks. It seems like you could make one that describes a polygonal area that the actor can't enter, and then create one of those and add it to the ego's blocks. Then when you move the bed, adjust the boundaries of the block (or your block class could even take a reference to the bed, and automatically update itself?).
-
Thanks Troflip, I've begun to look at the feature script. Looks like I can specify a node list which would be the list of blocks (I guess a set of x/y coordinates, not sure?). This may take me a bit to figure out.
Does anyone have any example code of this? I'm going to troll through the other fan games that have source code to see if I can shortcut some of the learning curve.
-
I actually ran into this problem with KQ2SCI. I just left it as a problem to solve for later on, though. I figured it'd be a bounding box solution.
-
An example of the class is something like this:
(class DontGoAbove of Obj
(properties
y 0 // The line not to go above
)
(method (doit pObj)
// Return TRUE if the ego is below y, i.e. it can be here
return (> (send pObj:brTop) y)
)
)
And then I put this in the room's init function:
(send gEgo:observeBlocks(send (DontGoAbove:new()): y(50)))
So in place of the doit method above, you'd need some kind of test to see if the ego is not inside the shape that defines the bed. You're testing against the ego's brLeft/brTop/brRight/brBottom - basically a box. But your bed's shape I guess would be more of an arbitrary polygon. Something like the separating axis theorem (http://"http://gamedevelopment.tutsplus.com/tutorials/collision-detection-using-the-separating-axis-theorem--gamedev-169") might work. But SCI doesn't have floating point numbers, I'm not sure if it's easy to implement it with integers.
-
I thought of another option, which would work if your bed was only in a small number of fixed places. You could have n different pic backgrounds that just draw the control lines associated with the bed's n different positions. Then use Rm::overlay to draw them on top of the main background.
-
Thanks for the sample & the alternate idea - I'll try them out. I'm pretty sure I can get option #2 working without an issue.
-
Nope, going with the first option. Troflip that sample code works perfectly, I'll just have to extend it a bit to create a bounding rectangle as best I can around the bed (maybe coordinates slightly smaller than the bed br values). If that doesn't work I'll fall back to drawing control lines.
Thank you for sharing this technique, I've never seen it before and it's pretty slick.
EDIT: Yeah, so now I have a class that is the inverse of the Cage class. Makes perfect sense!
-
Here's my code, works all right but really I need something better than a bounding rectangle.
(class DontGoRect of Obj
(properties
top 0
left 0
bottom 0
right 0
)
(method (doit pObj)
(if( (>= (send pObj:brTop) top)
and (>= (send pObj:brLeft) left)
and (<= (send pObj:brBottom) bottom)
and (<= (send pObj:brRight) right)
)
return(FALSE)
)
return(TRUE)
)
)
And in my room script, in init() (oh yeah, make sure this is executed AFTER you init your view :) )
(send gEgo:observeBlocks(send (DontGoRect:new()): top(- bed:brTop 15) bottom(bed:brBottom) left(- bed:brLeft 5 ) right(+ bed:brRight 5)))
I agree, a polygon would be a better choice. However, this is close enough for now.
-
I agree, a polygon would be a better choice. However, this is close enough for now.
Glad to see you got it working.
One possibility is that you could add multiple of these to make sort of a "stair step" bunch of rectangles. Sort of a poor-man's diagonal lines :D. The ego movement might feel a little bit weird then though.
-
Exactly my thoughts, I can break the single rectangle into perhaps 5 (or as many as needed) smaller rectangles that are staggered diagonally. I can certainly 'layer' them, there's nothing stopping me from that.
I've attached a screenshot to illustrate, but we are on the same page I think :)
-
Just learned something new the hard way with my bed-moving. My code to move the bed was simply to set the new x & y coordinates of the view. However, if that's all you specify, the other values of the view remain unchanged - the ones I was interested in were the br values. They retained the original location of the bed.
To fix this issue, you gotta additionally call init().
-
Should you use the posn method? That should reset the base for you.
-
Never used posn() before, but yeah that seems to work too. Thanks for that tip as I suppose that there are circumstances where you wouldn't want to call init().
-
Progress report:
By my reckoning, I'm about 50% done with the game from a puzzle standpoint. Still have plenty to do and not sure how I'm going to get it done. My goal is to have a fully playable (i.e. winnable) game by the end of the day tomorrow, though the game will still be in the 'rough draft' stages.
I've got the room pic pretty fleshed out (it has been decided, it's a one-room game). My views need lots of help, I still need to completely recreate the ego view and I stole one of Doan's characters from Betrayed Alliance for a temporary NPC that I'll also have to redo. If anyone can point me to views in a fan-based or Sierra game where the actor is wearing a robe and an actor that is in a nurse costume it would help (or anything remotely close!). That way I can just use those as a starting point and modify them as necessary.
Oh yeah, and as for the 'bed' I need to add some loops to the ego so he can push the bed around the room. No sound as of yet, no titlescreen, none of the 'storytelling' has been implemented yet.
-
Somehow, looking good at this point. There is something to be said about sacrificing sleep.
DONE:
- Game is playable/winnable
- Testing by 3rd parties has begun (wife and kids)
- Titlescreen and intro complete
- Scene transitions complete
- sciaudio wired in and music complete
NOT DONE:
- Death sequences
- Final win sequence
- Sound effects
- Right-click looking
- Redraw of ego & 1 NPC
Ran out of heap space this morning. However I was able to completely free it up by running the CreateTextRes tool and it gave me 10K heap back.
-
I'm running into an issue with an animated view and displaying a print dialog over the top of it. Has anyone figured out how to avoid the partial white 'border', which is displayed with each print statement?
I've attached a screenshot illustrating what is happening. It's the white pixels to the left of the print window, partially obscuring the door view.
EDIT: What appears to be happening is that part of the underlying view becomes transparent, and the portion of the pic underneath is displayed. Still no idea what's causing it however.
-
It is a common issue... the best solution that I have come up with, which I admit isn't a good one, is to try rewording the print statement so that the overdraw doesn't occur.
I think it is being caused by the font resource and different letters being different widths. I could be completely wrong here, but I am assuming that the background being drawn for the print statement is based off each character being the same width and so when it draws the background it is expecting a certain size, versus when the letters are actually drawn and take up less space.
As for a finding a nurse, the style of clothing in Colonel's Bequest may fit your needs. Change Laura's dress to white and draw a little hat on her and call it done.
-
Thanks Cloudee - especially for the nurse view, it'll save a lot of time. Any ideas for an ego in a robe? I'm thinking about using Doan's wizard from BA, that might work.
As for the print issue, I'm hosed. I've got way too many print statements. I may look into a fixed-width font to test out your theory. Additionally, I could move the view further to the left which might avoid some of the print statements, but I think I've come up with a different idea:
It's a fairly static view here that is causing the issue (a door). I could use addToPic to add it to room pic, that should fix the issue. Then when I need to animate the door, just lay the animated door over the static door, perform the animation, then after the animation is done I can addToPic again. I'll need to create some views of the underlying pic to reapply over the areas that need repainting after the animation is complete.
-
You might also be able to get by with moving the position of the print statements, or possibly be presetting their width.... I think width is an attribute you can use.
-
I don't think I've ever seen that door issue before. For it to happen, does the door have to be actually animating when the print dialog comes up? The white pixels on the left aren't even a box, the top part is "diagonal"... weird.
-
It's showing what's drawn on the pic underneath the view... You'll notice the diagonal coincides with the top of the door, so in this case, it's the door area that just happens to be colored white. If it were red, you would see the red instead of the white.
It's really easy to replicate, just have a couple of views on the screen where the print statements show up, as long as they aren't addToPic then you should see it more often than not.
Sierra had the same issue.
-
Oh yup, I just realized that. I thought he meant that it stayed white after the Print dialog went away. I was gonna say it might be a bug in the template game, but you're right, it happens even in Sierra games. So frequent I guess I was just used to it :P
It looks like the white part edges are aligned to 8 pixel boundaries. So if you can ensure the left and right side of your print dialog end up aligned to those boundaries (that might take some work), you won't notice it.
Or, given that Sierra didn't even care, just ignore the problem and work on other more meaningful parts of your game.
-
If the white is from the door view becoming transparent why not simply draw the closed door as part of the pic and adjust the door view to include what is supposed to be on the other side of when it is to be open. Or maybe I am not understanding what is causing it.
-
Thanks for all the input guys - this is going on the 'nice to have' list.
EDIT: Both my actors are done now, the robed ego and the nurse.
-
Holy cow, there are already 55 games submitted for this jam! Lots of competition out there. I'll be polishing my game up to the bitter end (this Friday evening).
-
Still making progress, but getting horribly burnt out. I still have to put in sound effects, clean up the title screen and add credits. Then I can move on to the 'nice to have' list, but I don't think I'll get there as 'QA' will undoubtedly come up with a ton of changes to make.
-
Wishing you luck, gumby! What sort of sound effects do you need? I wonder if I can help in any way...unless your goal is to accomplish it yourself.
-
Thanks MI, I appreciate it. I think I'll try to do the sound effects myself, my goal is to finish this off by myself (with the exception of testing).
I'll make the deadline. It certainly isn't the game that I set out to do, but I think it's not too bad. I just want to make sure that I represent the community by creating a game that hopefully inspires others to pick up SCI.
-
And that WE all appreciate I'm sure! :) Especially troflip.
-
Woo-hoo! I'm done! It's submitted to adventurejams: http://jams.gamejolt.io/adventurejam/games/soulshade-asylum/60639
I've also uploaded it here, but need to work out adding a screenshot & getting it approved.
I was able to get nearly everything done that I wanted. Some animations got skipped, one of the puzzles is pretty bad in my opinion, but it's not a horrible game. I'd classify this as a 'beginner adventure', you should be able to get through it in under an hour.
-
http://sciprogramming.com/fangames.php?action=review&id=198
Pretty easy to do really ;)
-
fyi, these "install dos box" scripts never work for me, and I always end up having to set it up manually.
-
By the way, I included the source code but please don't look at it unless you want to run away screaming. I violated the 'DRY' (Don't repeat yourself) principal all over the place :o
-
fyi, these "install dos box" scripts never work for me, and I always end up having to set it up manually.
That one is an older one that has issues. Be sure to check the "Use different DOSBox location to browse to where you have DOSBox installed.
-
Collector, do you have a newer version that supports sciAudio? I could repackage the game and re-upload it.
-
Congrats, Gumby! And good luck!
-
I'll have to look. If I don't find it I'll just write a new one. I don't think that I ever repackaged the run utility in a new setup wizard.
-
Thanks, I appreciate it Collector.
-
I could just do a whole installer for it Like I did for Doan.
-
Sure, if you've got the time I'd love it.
-
http://sierrahelp.com/DL/SoulshadeAsylumSetup.exe.php
-
Thank you sir! I appreciate it greatly.
-
This one simply includes DOSBox in a sub folder of the game. Given the target audience some may have never dealt with DOSBox. It also does not use my site's resources for the installer. I set the publisher as SCIprogramming.com so that the installer links would point to here.
-
Yeah, I gave it a test run and it looks great. I replaced the previous game download on gamejolt.
Thanks again, especially for the fast turnaround considering I gave you no time to do it in :P
-
Just trying it out, there's a fairly serious bug I think where you can't actually view your inventory. I picked up a total of three objects and pressing F4 just yields the response "You're not carrying anything".
-
Yeah the inventory screen got sacrificed unfortunately :( Just ran out of time.
-
A cosmetic thing, in the intro the title flashes if the cursor is over it.
-
Wait MI, I misread your comment. Not only did I not implement the inventory screen, I flat out didn't implement the inventory at all (and that was a complete oversight). That is a pretty bad bug. The only good thing is that there isn't a lot of things to pick up/put down. But still, it would be nice if at least it would have listed what you are carrying!
Collector: You are right - another miss on my part. If I had just used AddToPic to the title view, it wouldn't have that horrible blinking.
Ug guys. Just too many things to keep track of :-[
-
That's ok. It's practice.
-
Practice to see what it was like to have Ken cracking a whip over you to get the game finished?
Gumby, I suppose you can always do another version for bug fixes after the contest.
-
Yeah but then I'd be tempted recreate the game how I originally envisioned. A good point though, if it really bothers me I just might.
Not soon though, need a break :)
-
Ug guys. Just too many things to keep track of :-[
Well Gumby, I hate to say it, but on the inside I am smiling... Not because I wanted to see you make a game with a few bugs but because of the endless lists of bug fixes that you always managed to uncover for me. ;D Just goes to show how important that play testing is.
Good work though in getting it started and finished in a week time frame. I don't think I could do it without cheating and starting on it early.
There was a game though I saw listed on the jam site. As of last night it hadn't been submitted yet, I haven't checked back yet to see if it is there or not. But I couldn't help but think that it should definitely be made in SCI, Mixed up Mythology.
-
Well Gumby, I hate to say it, but on the inside I am smiling... Not because I wanted to see you make a game with a few bugs but because of the endless lists of bug fixes that you always managed to uncover for me. ;D Just goes to show how important that play testing is.
Touche, touche :D. Yeah, if I had to do it again, I'd say I should get it done in half the time, then spend the other half of the time in an endless test/fix loop until the end of the jam. I thought my playtesters did pretty well, but they aren't really adventure gamers. Still, they gave me a massive laundry list each time they played it of inputs that didn't work as expected. I also got some feedback from my brother and he tore it apart too - but this was after I submitted it for the jam, so too late to do anything about it. Let's hear it for waaaaay more testing.
Good work though in getting it started and finished in a week time frame. I don't think I could do it without cheating and starting on it early.
Oh and it was a 2 week jam, not one week. If it had been just one week, forget it :).
-
It's definitely a feat to finish anything even in a mostly-complete state in two weeks. Especially for an adventure game. I'm sure many of the other contributions have similar issues as well. Cheers.
-
Thanks MI, haven't had a chance to check any of the other entries yet. I probably should, it might make me feel better. Or not... :)
-
Sir... WTF :o
I just finished Soulshade Asylum... uhm
Can you retain your sanity long enough to solve the murder and escape?
-
Sir... WTF :o
I just finished Soulshade Asylum... uhm
Can you retain your sanity long enough to solve the murder and escape?
What.... you didn't like the ending? I believe that is still an accurate description ;D
-
tough game. I'll still stuck in the first room! lol