Goal: Create a procedural, 2D, action RPG like the old Zelda series (sort of) in January.
Team (listed alphabetically):
Goal: Create a procedural, 2D, action RPG like the old Zelda series (sort of) in January.
(Copy/pasted from here):
- Tech stack: the absolute best way (IMO) to get feedback and see results is to put our games online and make them web accessible. I planned to upload them to Kongregate. If you agree, using a web stack is more important than, IMO, reusing code from a single month session.
- We wrote a bunch of throw-away code for the PCG shooter. It’s messy. It’s copy-pasted. It’s called with different cases which are not related. It constructs objects strangely. I would rather start (mostly) fresh and learn from those lessons, instead of carrying existing code along – if we can avoid it.
- For prototyping, I’m human too, and this is the best way I know. I’m not saying this is THE end-all definitive way; nor am I saying we shouldn’t design up front – we should. But design docs, by the time you start implementing and see the idea, you realize that it’s not fun, it’s too late (and expensive) to rewrite 100 pages.
Finally, I personally am a huge fan of procedural content. I wouldn’t store rooms and connections in a JSON file; I’d rather generate them dynamically (fresh) at runtime each time.
The story/theme killed us by arriving late last game. Let’s get that clarified up front this time.
Also, my wife asked about our December game; I realized then it won’t play on her laptop (no mouse – touchpad is very crude for a PCG shooter). Ironic, because I picked a “laptop-safe” resolution (1024x576)/. Let’s try to be more inclusive this time by building controls that are, perhaps, keyboard-only?
Also, you (and perhaps Roketfiq) wanted game scaling. Cool. You understand the concept of virtual memory right? (16GB as a continguous virtual RAM space according to the OS, but it’s 4x 4GB chips of physical RAM). Let’s treat the game as 1920x1080 “physical” size (the actual game world size / real size), and scale it to the nearest version for the user – we can start with 1024x576 to start (53.3%) and worry about making this optional / auto-detect later.
I’ve never developed for browsers.
Can you recommend a stack?
What language would you be planning to use?
CraftyJS is good for prototyping. Best system I ever used (I like OO programming …). Easy, fast, but lots of quirky bugs and behaviour.
I like HaxeFlixel a lot. Based on Haxe, so cross-compiles to everything: web (JS and Flash), desktop (C++), and Android (Java/C++). That means more eyeballs for our games, hopefully. But Haxe is a bit crummy (it’s like a compiled, strongly-typed JS), and HaxeFlixel is very “Flash-like.”
Guys, is this bundle any good? Know about any of this software? Also, I know this may be a dumb and repeated question, but would you buy RPG Maker VX ACE or MV at this point in time? Ace is on sale for $6.99.
You probably picked the wrong thread for this (this is not the general gamedev thread we started).
VX Ace is good but limited in some ways (like screen size) and five years old. MV is the New Thing, which IMO is worse in a few ways. I bought it regardless, hoping to eventually master its failures and produce at least one good game with it.
I paid $39.99, which is usually their sale price (50%). I wouldn’t spend money on Ace, as it’s an outdated product.
Just a heads up that I am still around.
So far I have coloured blocks on a 2D map.
I have basic movement controls for the player block.
Originally I was using the Fourway controls to shift the box in cardinal directions at a set speed,
Decided I wanted to try restricting movements to discreet grid co-ordinates (Like the older style RPGs) so now I have bound keyboard events to the player object to monitor directional keystrokes and evalute the player box on each frame to detect if it is moving and apply a discreet movement if it is idle.
Player object now “Tweens” between set positions. IE Set change in attributes and timeframe for change to occur.
I have wall objects that on collision halt player movements
Currently not working correctly with the new movement scheme, currently halts player movement, but does not kick the player object out of its’ boundry or prevent further movement from new commands.
Currently acting more like glue than wall.
Previously working flawlessly with Fourway movements
Prototyping enemy object class,
No AI yet, but I have figured out how to process object on frame
- Previous proof-of-concept using player object auto-moving
Have enemy subclass, Currently just displays object box as a slightly different shade of red.
Intending to write AI functions within specific subclass this time.
Prototyping Area transition box
Previously just teleports player on local map on collision.
Currently teleports player off screen.
Currently used as proof of concept for conditioinal collision (IE collision with objects ‘Solid’, different from objects ‘Enemy’ or objects ‘Transition’
Intended to trigger area reload, drawing new walls and enemy placements
Blue: Player, Green: Map Transition tile, Bright red: Enemy type 1, Dull red: Enemy Type 2, Black: Wall
This time I am trying to use independent classes for each type of object, using a simple hirachy for inherited attributes:
(File: components.js) * Grid - Base object for tile based objects -Attributes X,Y,Height,Width -Function at(x,y) ie: Crafty.e('Player').at(10,10) to spawn player object at grid position x=10, y=10 * Actor - Base object for sprites -Requires (Grid,Color, Canvas) (File: player.js) * Player - Player object - Requires (Actor, Keyboard, Collision, Tween) - set attribute: colour(Blue) - Bind event: KeyDown - Bind event: KeyUp - Bind event: EnterFrame //Check object idle&&Player requesting movement, trigger movement. - Collision: Wall -- StopMoving() //Event - Collision detected with object having property "Wall" - Collisoin: Enemy -- Die() //etc, etc - Collision: Transition -- MovePosition() (File: Enemy.js) * Monster- Base enemy object - Requires(Actor, Enemy) //Gives object property "Enemy" - Set attribute: Color (Red) * Monster 1 - Specific enemy subclass - Requires(Monster) - Set attribute: Color (Dull red) (File: wall.js) * Wall - Requires (Actor, Wall) //Gives object property "Wall" - set attribute: Color(Black) * Floor //Not currenly required. Ultimately would like to apply randomly selected sprite or creating visually intresting terrain on map generation (IE Random cracks and marks in floor tile). - Requires (Actor) - set attribute: Color(Grey) * Transition - Requires (Actor, Transition) //Give object property "Transition" - set attribute: Color(Green)
For those intrested, I have pushed a copy of my code to gitub
I plan to take a look inshaAllah once I’m done with Dajjal’s Minions.
FYI, I wrote something like an RPG in CraftyJS a couple of years ago: https://github.com/deengames/a-day-and-a-night/tree/craftyjs
It included some “fun” dev features like:
- Click a button to dynamically reload all JS files
- Map data came from JS-wrapped JSON files
- Speech bubbles!
An RPG is way too much work, and CraftyJS … the quality just wasn’t cutting it. So let’s see how this goes.
Since I started playing with this, what I am imagining is much simpler.
The player moves around the world, no weapons, no combat.
Must find keys to open new areas.
If gets touched by a monster, game over.
New game, new world.
Player must make it through x number of areas to escape to safety
On new area being reached, new monster types are added to the mix with different mechanics.
Focus on map generation, path finding and line-of-sight AI.
@ashes987 I will have to read through your sorce. I can’t quite picture how to setup map data in a json file.
The idea I was playing around with was using an image then scanning pixel colour to generate tile locations.
Red: object type
Green: object subtype
Blue: additional argument.
So a white pixel is parsed as:
Red: 255, object is floor
A black pixel is parsed as:
Red: 0, object is wall.
So the designer can easily draw up map designs in any paint program calling object spawns using RGB codes such as:
To add monster spawns, draw a pixel of RGB=200,2,0 to parse as
Red = 200, monster
Green = 2, monster type 2
Blue = 0, no additional parameters to set.
To add map transitions draw a pixel of
RGB= 100, 4, 2 to parse as
Red = 100, Door
Green = 4, right-top position (links to a left-top)
Blue = 2, requires key #2 to open.
The scheme you’re designing sounds (frankly) hard to understand/master. I would say “go with a tile editor like Tiled instead and output as JSON” or better yet, just generate everything dynamically – why bother with static maps?
JSON is just a format/transport. Seriously, forget JSON, and just use simple text to describe your format until you need something better. Efficiency is pointless when you parse once and forget it.
Your first paragraph reminds me of my Super Masjid Brothers idea. Mario clone, with a twist: find items (eg. keys), fix things (eg. go on the roof, get five roof tiles, and patch holes as crows peck at your eyes). Boiler room (boiler will explode, escape in 30 seconds), etc.
Sorry to intrude, but @Severok’s suggestion sounds really cool.
If @ashes987 doesn’t like the extra code you need to write to read pixels in the image, you could simplify it 1 step by using characters:
XX = wall
__ = floor
o9 = key 0-9
t9 = transition 0-9
Ascii could work, parsing a text file would be very easy.
For reference, here is an example of what I was thinking.
The original image is a 50x25 bmp image.
The designer starts by with a white background and draws black pixels to indicate wall locations.
Adding coloured pixels to indicate player spawn (green), Map transition tiles (blue), and Enemy locations (Red)
When happy with the locations, you can go though setting the colours to the contain the RGB data colours
Im still not sold on specifically how to map the data to different RGB codes, so the pallet is variable for the moment.
Since I don’t anticipate many variations of each object type, I have scaled the 2nd argument (Green value) by 10 for the moment to make the data more visually appartent on the map image.
Eg, the argument 2 for map transition tiles determine what direction they link. Going from
- Top left: G = 0
- Top center: G = 10
- Clockwise around the boundries, then 9 floor based regions for ladders/stairs.
This way designers can actually plan out room design for more visually intresting maps and intelligently placed enemies to obstruct players on the way to map transitions.
I would like to see these room images placed on a larger grid image of say… 20x20, then have the code break the master map image into an array of 20x20 sub-images, randomly selecting one on entering a new room then scanning the room subimage with nested for-loops spawning objects as directed by the pixel colour data.
IMO, I don’t see this as being easy to understand or to manage. Why would we do this, when we can have simple text files? Why generate static content at all, when we can do interesting procedural generation?
Anyway, feel free to proceed in whatever way you deem best… it’s an experiment after all.
I don’t see parsing pixel data as being anything exceedingly challanging and storing the data in an image lets the designer plot data in a 2D field that can be simply/visually audited using any number of image editors.
Anyway, That I am calling that project I was playing around with at the absolute minimum MVP stage now.
It is a functional game with the most core concepts in play.
That is to say that it currently meets my scope after cutting everything I could think to cut.
It spawns a 50x25 field,
Populates it with wall borders and procedurally generated sections of wall (Have not written anything for parsing premade map data from file
It has contextual collision detection
It has a control lable character
It has enemies + simple AI
It has a goal (Reach green square to move to next floor) and a failure state (Get eaten, aka touched by an enemy)
It is very simple, it looks like it was made for the atari, it has a heap of existing bugs (Mostly relating to things spawning outside of the play area), but it is a game.
It is developed far enough for me to get my feet wet with the tech stack, and to see if this game mechanic works, is fun and is worth developing further.
Everything you can ask for in a prototype.
If you want to check it out, the repo is at
I think the key question here really is: is it fun or not?
I like how the AIs act all slow and stuff until you get in range, then BAM! overdrive.
Couple of small things I would tweak:
- Exit green is hard to see against the grass-green
- Enemies are as fast as you. Literally, in overdrive mode, they’re unavoidable completely. You should be at least a tiny bit faster so you can outrun them or something.
Fun or no?
I can see the making of something there.
If it had linked areas that give a sense of exploration instead of endlessly generating random rooms and add keys to open up new paths then I feel I would be happy with it.
Hold shift to sneak, agro range drops but so does your speed. Currently drops to nothig but that can be adjusted. Right now it is something of a cheat button.
I have found that it is fun when you get around floor 6 and there are many more walls.
Plan your route to take advantage of cover.
Get monsters stuck on the walls so you can pick a path around them, hopefully without agroing others.
I would like to experiment with path finding and line-of-sight agro.
The more I tinker with it, the more I like the idea of omitting combat, giving a survival horror tone like SCP containment breach or Amnesia rather than a traditional ARPG like Zelda.
Our tastes may differ, but I find I usually prefer games without combat mechanics where players have to work around problems rather than push through them.
I have some ideas for more enemies, AI and mechanics etc, but that fell outside the prototype scope.
Need to focus on having a fun core concept with the bare minimum that can be enhanced with content rather than using content to make it fun in the first place.
I agree with your analysis about the makings of something. I never reached level six – only felt unfairly placed immediately near enemies, or where 2-3 of them blocked the only stairs down, and I can’t outrun them.
By all means, please continue to experiment and refine your prototype. I would suggest adding more walls more quickly, in addition to my previous recommendations.
(Migrated to this thread)
My earlier post on the migration thread put an idea in my head that I had to toy around with tonight.
So I wrote a simple map generator:
Blue: Ocean Yellow: Shore Light Green: Grassland Dark Green: Forest Gray: Rock Colours = Place holders for sprites
What I am thinking is taking the cells generated by this algorithum and breaking them up into an array of sub-section and using them to generate individual game rooms for my survival prototype.
The game could be something like… Make your way around the island looking for parts to escape.
BTW- I am fine with putting the current project on hold to work on this. It sounds like a good cause.
I probbably did it the dumb (read: Brute force) way but my proceedure is:
- Initialise a 2D array, all water.
- Place a “Seed” land tile in center of map
- Run a randomised 5x5 blur filter of the map x-number of times (Weighted against the number of neighboriing land tiles)
- Scan map for ocean boundry tiles and set as shore.
- Scan map for land tiles with small chance of being set as Tree or Rock
- Run randomised 3x3 blur filter of max x-number of times, filtered for Tree and rock tiles.
- Scan final array and spawn tiles for set tile-type.
Here’s a long, good read that’s food for thought: http://www-cs-students.stanford.edu/~amitp/game-programming/polygon-map-generation/
Remember the old gamedev adage: if you can fake it, fake it! No reason to over-complicate things