L33TMaster
Member
I lurk and mess with tiles, not much else to say.
Posts: 108
|
Post by L33TMaster on Dec 15, 2014 20:34:26 GMT
I hear you man good luck and don't pull your manager over the table(brother did that)
|
|
|
Post by bastardcode on Dec 17, 2014 0:08:14 GMT
VERSION 0.24fa alpha ## Additions ## - Added placeholder item for future testing of inventory system
## Changes ## - Fixed Bug in player controller execution code, couldn't reference parent entity properties (#0010) - Updated Enemy controller to use the same bugfix as the PlayerClass - Cleaned up some deadwood - Added simple item collection ('props' laying on the ground of a given chunk) - Added system for initializing whole item collection at map setup - Inventory component added to PlayerClass - Fixed stupid bug involving new component being added to the wrong class (I noticed this one completely by accident) - Fixed discrepancies with input code which would have eventually became a problem - Fixed stupid bug with copypasta for old movement code - Fixed a hard to find bug involving my terrible use of find-replace - Added a customizable debugging function, for calling the console as needed and testing variable values / functions independent of context
## Notes ## Find n' Replace is bad m'kay? Don't use it for changing tons of redundant method calls. Otherwise you end up with controllercontroller.input instead of controller.input like you wanted..and javascript is a pain in the arse to debug. Also, I've ramped up development by streamlining the roadmap to be less stab-me-in-the-eyes aweful. Updates won't be out any sooner, but they will be more meaningful, and have slightly more visible progress along the way.
FORWARD!!!!!!!!!!!!!!
|
|
|
Post by bastardcode on Dec 17, 2014 23:36:18 GMT
VERSION 0.28ad alpha ## Additions ## - Mouse Input support added - Tilepicking implemented - Mouse input triggers a new turn, not just keyboard input.
## Changes ## - Updated to phaser.js 2.2.1 - Significant performance & memory improvements due to update - System can now detect what button on the mouse was pressed - Fixed bug in mouse detection output - Fixed minor bug in mouse detection based on variable instead of string - Got tilepicking based on mouse x & y / TILEXY working - Fixed bug with floating point values in tilepicking. Much love for Math.floor() - Changed debugger to indicate both where it was called from, and output a value based on the arguments passed in.
## Notes ## I was worried the update would break the current build because the new version of Phaser (what I'm building this on) had API changes, but everythings still running smooth as gravy. A couple new bugs related to mouse picking and coordinates, working on them as I go. Nothing serious.
FORWARD!!!!!!!!!!!!!!!
|
|
rafe
Junior Member
Posts: 97
|
Post by rafe on Dec 19, 2014 17:48:05 GMT
Do you think you could make two types of cars? In original rogue survivor, all cars are broken. It would be nice to be able to actually use some of them early in the game. Maybe with a "electronics" or "stealing" perk. You could also make a "car keys" item, and link each one to a separate car, which is obviously too complicated. Stealing perk can also double as a skill that lets you steal something random dom other characters, with a % of being discovered and attacked.
I know its too early to implement something like that, but it is never too early for ideas.
|
|
|
Post by bastardcode on Dec 20, 2014 10:41:32 GMT
Do you think you could make two types of cars? In original rogue survivor, all cars are broken. It would be nice to be able to actually use some of them early in the game. Maybe with a "electronics" or "stealing" perk. You could also make a "car keys" item, and link each one to a separate car, which is obviously too complicated. Stealing perk can also double as a skill that lets you steal something random dom other characters, with a % of being discovered and attacked. I know its too early to implement something like that, but it is never too early for ideas. I don't want to give too much away. As you said, it's too early to consider implementing things like that. Vehicles would be very OP to the original game, so any new mechanics would have to extend whats already there, instead of modifying it. tl;dr. If I implement vehicles it will only be after all the other original parts. And once I do, it wouldn't be for travelling around in the city, but for things like waypoint travel between districts, or "Organ Trail" (play that game, it's awesome) style movement between major areas. Of course, being javascript, if anyone want to modify it themselves it'd be cake. Half of my LOC are comments. Volumes of comments. I have the memory of a goldfish and can't be arsed later on to figure out wth any section of code does.
|
|
|
Post by moraldeque on Dec 22, 2014 23:13:48 GMT
You salty magnificent bastard. I love Rogue Survivor. I tweak/rebalance my Rogue Survivor constantly, changed the music, modified a lot of Deon's fantastic tileset. I'm tempted to talk about what I've done, not like it matters because it's not as L33T as writing code (you) or a full tileset overhaul (Deon).
Like you, I love this damn game. I haven't tried Cata personally, but I know it's far more feature rich and in depth. The thing that keeps me coming back to RS is 1. the ease of play to just jump into the apocalypse as a random shmuck and try to make it and 2. The NPCs.
Are NPCs in Cata now better? I don't know. The NPCs in RS were left quite unpolished, but the real pull of this game was how you're not alone and other NPCs are actively grabbing up food and fighting the good fight with you. They have to play by the same rules as you do, and I love that shit. Project Zomboid is currently the only other game I know of getting NPCs of higher quality in the game, who'll form groups, make bases and alliances, betrayals, go on raids, have arguments, have to put a sick one down. You name it.
To type into google "Rogue Survivor Dead" and find this forum and what you plan to achieve and seeing the consistent updates you've been making is too much to believe. You're not talking about how amazing you'll make the game while it's clear you're just drawing sprites *cough* Tao/Tau/whatever *cough*
After seeing all this you're doing, I checked up on Dagger XL, system port remake of Daggerfall and that guy hasn't updated since around March. *cries*
So basically, I thank you for loving this amazing abandoned game. You also know what makes a good game, what's important, the features you need and the features that you don't. So many people are obsessed with "fluff" and not "crunch".
You, sir. Are all crunch. And I like that.
For getting right down to it. +1 For enjoying the randomized characters you play as. +1 For believing more options are still always better. +1 For planning a clean, simple vintage zombie game first. +1 (I did lots of work on my special zombies, made Skellies dogs, made upgraded dogs have 2 and then 3 heads. Shamblers grow fat and grotesque and fresh zombs become fast, naked crimson head-types that look like they're screaming. Masters are damage dealers that grow into muscular Juggernauts. But I have to say good old simple Vintage mode really is the best.)
I'm eager to try any build you deem ready for us peasants to test. I'm enjoying watching how you prioritize everything Walls/collision -> Making a viable working landscape -> Making entities and going back and redoing shit because you know it'll hinder performance if you don't -> talkin' bout functions and shit. And the fact you say you comment everything makes modding your code in the future very exciting.
Roguedjack said way back that he'd have to stop and focus on getting a boring job. You got a boring job AND still work on this. *claps* We aren't paying you, and you aren't asking us to. So don't expect me to feel I'm entitled to you finishing this, but I know you kinda want us to, to keep a fire under your ass (even if you say you don't care, it probably does help).
Enjoy some Cata and have a Merry Buy-Shit-And-Stick-It-Under-Dying-Tree Day, god knows you've earned it already for making ours. (Yes, just giving us that believable hope again is enough.)
|
|
|
Post by bastardcode on Dec 23, 2014 5:03:40 GMT
VERSION 0.28ba alpha ## Additions ## ## Changes ## - Fixed bug (#0011) "Prop placement not respecting y coordinates", wrong variable for Y axis. - Fixed bug (#0012) Tile picking problem was caused by comparing the wrong actionQ axis against the given propStore axis. - Fixed a few other minor issues ## Notes 2 New bugs added to tracker. This is just a small update because I can't keep my eyes open any longer. Always busy during the holidays but I'm becoming more efficient at this. Glad to have you on board MoralDeque. I agree most people are obsessed with circle jerking and group therapy called 'discussions.' Too many people are full of timid half-hearted intimacies and political correctness. If you went through the effort to change all that then your lying when you say vintage is the best. And if your going to self promote, then don't put it in parenthesis. I think it's rich that you believe Deons all that great, or that I'm that good. Reality is no ones special. Doing something good is a lot more about persistence. Bashing your head against the wall just a little longer than the other guy, until you figure out how to bash it better than he does. And they call those people 'experts'. Professionals just another word for an "amateur who figured out how to get paid" FORWARD!!!!!!!!!!!!!!!! But I'll forgive your niceness for the Dying-Tree reference. Made my day.
|
|
|
Post by moraldeque on Dec 23, 2014 7:43:38 GMT
Haha, I apologize for being so "nice". Oh wait, I mean "Fuck you, buddy!" Yeah you and Deon aren't the "best" in a grand sense, but in my little world you have some value. Deon made the game playable without my eyes screaming, and you're blowing your short fickle lifespan working on something that happens to please me. When I first played RS all I did was the one with the evolutions. So over time, I redid their stats and changed their looks. But when I craved zombies again I came back to RS and I tried vintage and it's classic human zombie only approach. So yeah, I did all that work and don't even use it. But that's how my ass rolls. I modded Morrowind (still am) out the wazoo and I don't even sit down and play that anymore. I just love adding crap and tweaking rules more than actually playing the games I have these days. I guess me plugging my work in parenthesis was to make it appear optional to read. Why do you want to make this Multiplayer? It's a nice feature but it puzzles me how you're going to incorporate this into a turn based movement game where you're usually given first dibs over everyone else on initiative. If Player X and Player Y both want to move to spot Z, and they have the same speed and initiative, who gets the spot? Do they just bump into each other? Do they merge into some horror? Do they declare "There can be only one!" and start an epic fight to decapitate the other? Also, what does the algorithm you found for LOS and FOV entail for your game? Do you want it to be the same as RS where you have a 360 degree sight? Or the direction oriented sight of say Unreal World? It would be pretty cool to be able to sneak past zombies instead of just staying out of their fov range. On the other hand, having to turn and orient yourself makes the game a lot more complicated to move about. ...But on the other OTHER hand, wouldn't a limited cone of sight reduce the simultaneous LOS computations and shit? Oh, zombies that realistically attract to sound and naturally form contiguous hordes is friggan great. Project Zomboid does that, and rain makes them randomly move about due to the sounds being made. I guess I should take your sig to heart and just shut up until you actually ask for an opinion or ideas for a particular feature. The house has to be built first and made sturdy enough not to collapse before I can talk of what color to paint it. But I am really goddamn eager to help however I can. And as for your "They break barricades too quick." All I could do was lower the zombie damage and reduce npc health and weapon damage to compensate, which helped to make them have to bump against doors ominously for a while, but that made healing too easy.
|
|
|
Post by bastardcode on Dec 26, 2014 23:04:23 GMT
Why do you want to make this Multiplayer? It's a nice feature but it puzzles me how you're going to incorporate this into a turn based movement game where you're usually given first dibs over everyone else on initiative. If Player X and Player Y both want to move to spot Z, and they have the same speed and initiative, who gets the spot? Do they just bump into each other? Do they merge into some horror? Do they declare "There can be only one!" and start an epic fight to decapitate the other? Also, what does the algorithm you found for LOS and FOV entail for your game? Do you want it to be the same as RS where you have a 360 degree sight? Or the direction oriented sight of say Unreal World? It would be pretty cool to be able to sneak past zombies instead of just staying out of their fov range. On the other hand, having to turn and orient yourself makes the game a lot more complicated to move about. ...But on the other OTHER hand, wouldn't a limited cone of sight reduce the simultaneous LOS computations and shit? Network coding and MP is something I've wanted to take a crack at for a long time. Turn based movement is problematic, unless we're only talking about 2-4 players which is reasonable enough, although in this age most people wouldn't tolerate it. Mulling over contingencies is the type of ACTUAL discussion that has to happen, and not circlejerking. "If x, what about y and z?" And my answer is "I don't know." We'll cross that bridge when we come to it. I'm already anticipating implementing real-time or semi-realtime. There was another guy on these forums that did just that, and if not for balance, it would have been fun. Also, the LOS/FOV algorithms return the same results as the ones in RS, they just work differently. Performance differences between HTML5 vs. JS and all. Dunno yet. Coding can be slow and painful. Good thing I'm a Masochist. ;]
|
|
|
Post by bastardcode on Dec 29, 2014 0:58:12 GMT
VERSION 0.31da alpha ## Additions ## - Distance check to prop/object interaction now working - Picking up items (sort of) works now - Picking up an item causes it to disappear from the map
## Changes ## - changed actionQ from array to object for debugging - Partial solve for bug (#0014). actionQ sometimes returning undefined causes nextTurn to bail out, meaning keyboard input is registered but nextTurn becomes uncallable. - Fixed bug (#0014) Was an autofocus problem with the debugger, ironically. - Removed some sections of deadcode - Cleaned up debug code and error messages, fixed a minor problem with null arguments being passed. (should have default values for the parameters to indicate when I forget to send an argument or three) - Cleaned up old controller code in the gameDebug function - Reintegrated actionQ, partial fix for null return error bug (#0013) - Now checks object picking against both x and y tile coordinates vs the whole prop store for the given chunk - A couple new bugs added, others fixed. - Debugger now returns the number of items or 'props' left on the given map chunk - A bunch of other things that I wont bother with. I'll just increment the version, ha.
## Notes ## I'll probably have to decouple the scripts at some point and implement a clean structure. Compost, as they say. It smells like shit, but helps things grow.
FORWARD!!!!!!!!!!!!!!!!!
|
|
rafe
Junior Member
Posts: 97
|
Post by rafe on Dec 29, 2014 14:24:49 GMT
Keep up the good work!
|
|
|
Post by bastardcode on Dec 30, 2014 3:54:34 GMT
VERSION 0.32eb alpha ## Additions ## - Partial inventory key implemented. Doesn't show anything yet in normal mode, but useful for debugging.
## Changes ## - Removed a TON of redundant code and comments - Fixed a helluva clever bug caused by an almost completely invisible undefined value (was locking up the screen only if I was testing WITHOUT firebug, which was, until recently, never) - Fixed another invisible bug in registerMouseAction() where the input on the mouse and action var was only being reset if input was being detected. Meaning that, in some circumstance the controller code would repeat the input from a previous turn because it detected these variables had input to be processed still, even if no input of that kind had happened in the current turn. - Fixed bug (#0017) that was caused by the wrong ordering of processing in nextTurn, where input was checked BEFORE player movement was propagated, so input that dealt with interactions with nearby tiles was mistakenly using the players OLD coordinates. - Added map key for debugging purposes. - Fixed bug (#0018) related to bug (#0017)
## Notes ## I added a simple index to the main source, sort of like 'chapter lists' in a book to make finding a particular section easier. This instead of doing the proper, non-lazy thing, and breaking the source down further into more files. Why? Because I can.
Also separated out estimated development time between bugs and features for better time tracking. I figure half my time is spent in distractions, and fixing head-scratchers, and with my current evidence-based-scheduling ratio of 1.55 (that means my time estimates are 50% lower than the actual amount of time it takes) and looking at the roadmap, it's going to take 97.17 hours + ~50 for bug fixing, for a total of roughly 150 hours dev time. Averaged over the whole time, with a little over 2 updates per week, and roughly 8 hours of dev time, with only 4 hours being fully utilized, or 50% efficiency (family and work tend to do that), thats..
150 hours of dev time till release / 8 hours of dev time per week = 18.75 weeks or 4 1/2 months, or another 38 (actually 37.5) progress updates to go.
Discouraged yet? No matter..
FORWARD!!!!!!!!!!!!!!!!!!
|
|
|
Post by bastardcode on Dec 30, 2014 22:45:28 GMT
VERSION 0.34fb alpha ## Additions ## - E for Equip, key cycles through inventory. - Inventory Key
## Changes ##
- Equipment slots on playerClass (not accessible yet) - Fixed wrong variable name in item pickup logic. Was player.contents, should be player.inventory.contents. - Fixed bug in accessing inventory, because this time I was referring to it as player.inventory, instead of accessing the actual array. The class has an inventory *component* object, that has two sets of props, player.inventory.content and another for items their wielding/wearing, player.inventory.equipped - Fixed undefined return when attempting to access empty inventory - Fixed undefined return when attempting to equip when inventory was empty - A bunch of other minor bugfixes. Obligatory version increment in 3..2..1.
## Notes ## Added a new todo to keep track of tasks that need done but are unrelated to roadmap features or bugfixes. Mostly maintenance stuff, to prevent things from becoming a problem down the road. Btw, this is longer than any project I have ever worked on. That doesn't say much, but if anyone has their doubts, just remember this handy phrase "Fuck you and your opinion" That is all =)
FORWARD!!!!!!!!!!!!!!!!!!!
|
|
|
Post by bastardcode on Jan 4, 2015 10:14:58 GMT
VERSION 0.35fc alpha ## Additions ## - Tentative Desktop Support added.
## Changes ## - Bug with state systems reverted for now. Need to do code maintenance.
## Notes ## I'm looking into various methods for packaging for native desktop support. That way I can minimize having to work on different browser implementations of various APIS, and javascript engines. Going with a node.js based packing system so I only have to code against the chromium engine. The initial dry run went off without a hitch. It was badass. Only tested on Windows 7, 64bit though. My new angle of attack breaks from the cycles of releases focusing on *features*, *bug fixes*, *features*, and repeat. What I'm going to do each update is to add a little of each per release - one bug fix and one new feature (minimum) for each post.
FORWARD!!!!!!!!!!!!!!!!!!!!
|
|
|
Post by bastardcode on Jan 6, 2015 4:32:05 GMT
VERSION 0.36fd alpha ## Additions ## - Gameplay window in standalone version now chromeless (no margins or obnoxious title bar) + sized correctly to the viewport
## Changes ## - States still need to be re-implemented, but the code by itself now works. Huzzah.
## Notes ## Prep work for setting up menus and other secondary screens. Seems like very little but a lot of what I change doesn't even go into the logs. Tons of it is testing, experimenting and working out weird edge cases.
FORWARD!!!!!!!!!!!!!!!!!!!!!
|
|