its Ibn Batuta right? was that a mistake or a deliberate choice to make a teeny bit off the mark?
massive scope creep… I think we can manage maybe 1 or two minigames out of what sounds to be much much more than that. Its also VERY hard to make any of the procedurally generated…
My Idea is very simple. Raiden X (be warned, audio) + some RPG elements regarding upgardes. Can make some fancy art and some fancy behavior with some of the weapons. Can add some story regarding why this guy is going around shooting stuff.
##KISS: Keep it Simple. salaams o/
#EDIT:
oh… I just saw nanobiology… Im cool with that. Still think its too big of a game though.
Ibn Battah is an intentional mistake. Battah = duck. So his arch nemesis calls him “Duck boy!” and he carries around a rubber duck (software engineering trick: tell it to the duck) etc. Plus, I don’t have time to research and make historically accurate games. Yet. That’s a big, but beneficial, thing we can do.
Agreed about scope creep, albeit it’s not that difficult code-wise. The main scope is art. But yeah, it’s a big game.
[quote=“Severok, post:23, topic:86, full:true”]
You seriously have to be the first one I have ever talked to who understands rubber ducks.[/quote]
Like you, I learned about this in a software engineering class. It’s so popular, Stack Overflow built their site format around that. There’s a blog post by one of the founders explaining that by the time you get 80% through your question, you should have already realized the solution yourself.
Maybe it’s not that common outside of software development shops.
I’m really enamoured with the idea of making a Clockwords Prelude “spiritual” successor/clone. In summary, you type words to attack monsters as they flow across the screen. You have a small pool of special letters, which do more damage if you use them. There’s also a mechanic where, the more of those special letters you use, the more you can unlock for subsequent attacks.
Your collection of special letters can grow, and you can craft stronger ones from weaker ones via a “boiler room” mechanic, including powers (poison, explosion, freeze, etc.)
I think it has a lot of potential (perhaps to include some Arabic). I think one person can reasonably make the core mechanics (type to fight + random monsters per level; boiler room crafting) easily in a week.
Top scrolling shooter, set in space with RPG elements.
Player plays a stage, collects bounty for completed stage + scrap collected from downed enemies.
Between stages, player uses the accumulated resources to upgrade their ship (Eg weapon loadout, enhanced sub-systems for shields, manoverability, etc) and hire crew for additional passive bonuses.
Some sort of map system could set a branching story line in some kind of conflict, so we can easily inject morality and possibly islamic themes in decision making (Morality vs difficulty/reward)
To further boost the RPG element with stretch goals:
We could add in pilot skills that grow based on how the player plays eg, If the game records a greater number of near misses, your pilot becomes more agile making you move faster and giving a chance to dodge shots that would otherwise hit. If you have a high accuracy ratio, your pilot adopts a conservative tactic where he shots slower but the shots do much more dammage or inversly if you have a low accuracy develops a ‘spray-and-pray’ skill that lowers your weapon dammage but adds spread.
Combat stances in the form of diverting power. Hit keys to switch between preset power settings favoring engines, sheilds, weapons or balanced. Dynamically swap between the stances as the situation requires to gain needed speed in a tense situation, soak up more incoming damage or lay into a heavily armoured boss.
Sounds very feature-rich. I like it. What I would like to distill it down to is the smallest set of features that still make it what it is. Sounds like that is:
Top-down scrolling space shooter with stages/levels
Collecting scrap from enemies
Upgrading loudout via scrap
Pilot skills
I would suggest (because I like making educational games) that the scrap idea has potential to turn into an engineering idea. For example, we can expand it into:
You collect different types of resources, not just scraps
Perhaps you have to refine, combine, transform, etc. them into other stuff
Researching technologies found from downing enemies leads to new usable techs
etc.
As I was telling Abrar: one thing I learned is that “if your game is fun as grey boxes moving around and no audio/images, it’ll be fun with full media. And if it’s not fun with grey boxes, no amount of media will save it.” That’s why I’m trying to distill out the core gameplay.
Also, branching levels that are in a procedurally-generated universe? In fact, are we going for PCG levels too? Maybe that’s not important at this stage.
How about PCG levels generated using parameters passed from a scripted branching storyline, maybe with a PCG world map?
Something like the script triggers a new level to start with the enemy type = Robotic, enemy density = High, enemy aggression = high.
Enemy type determining which enemy entities are enabled to spawn (Beyond different appearences and movement patterns, enemy types drop differnt kinds of loot)
Enemy aggression determining how difficult the enemies are (waves of light scouts, or full on assault craft)
Enemy density determining both how many waves spawn but also how large those waves are.
In terms of the story/lore integrating into arcade style mass-shootemup gaming, I am thinking that the main enemy types are something like:
Asteroid patches - Can appear moving between systems or on purpose in an attempt to gather minerals through mining.
a self-replicating robotic rebellion, story element where you need to head to systems to push them back or rescue civilians from areas about to be over-run
An insect hivemind. Similar to above
In various parts when hostile human ships (Pirates when traveling between systems or police/military if you make bad choices) are encountered the combat should be much harder with the encounters containing very few ships or even 1v1 in the style of a boss battle
I had an idea a while ago for a grid based crafting system for a space sim where:
Craft basic components from raw resources using a menu-based crafting system (Component are ordered then delivered in time based on how large a production/engineering facility you have on board)
Advanced components are built from simple components using the same menu-based crafting system.
The ship contains a number of weld-points around the hull, each consinsting of a 3x3 or 4x4 grid. Placing components on this grid decides what weapon or subsystem exists here, and its parameters
Eg: A gun barrel + chamber + hammer in a straight line forms a basic ballistic weapon, putting a feeder + ammo storage next to it on one side turns it from a semi-automatic to full-automatic (with the quality of these components dictating the firing speed and ammo capacity), Placing a gimble (Motors + platform) turns the static machine gun into a machinegun turret, placing sensors + CPU turns it into an automated turret that can be set for use as an aggressive AI turret or automated counter-measures against larger projectiles.
When the ship takes dammage, there is a very low probability that a subsystem takes a direct hit.
When this occurs, a random component on the grid is dammaged. The game at this point re-compiles the subsystems grid without that spot, and adjusts the weapon for how it would appear without that part in the grid.
Eg: in the above weapon, the CPU takes a direct hit, the automatted machinegun turret -> Manual machinegun turret. or if the ammo feeder took a direct hit, then the automatted machinegun turret -> automatted semi-automatic turret
@Severok I really like your section on enemy types. I forgot that asteroid mining is a big part of it.
I think we’re getting ahead of ourselves in terms of features. We have a lot of excellent ideas though mashaAllah tabarakallah.
What’s the simplest set of functionality that makes this a complete game? What can we cut and get away with, and what is the smallest set of things we can’t cut?
Crafting & storyline/art assets would be stretch goals.
I agree with your earlier comment, the game has to be fun as coloured boxes.
How does this sound?:
For core mechanics, I am thinking we make what is essentially 2 games:
The universe map that acts as the level select screen
Actual shooter game
overall game alternates between the 2 sub games:
Overworld map -> Sets parameters of shooter
Shooter -> Determines players resources and options on overworld.
Overworld mechanics:
We can use this as a hook to include story elements later
Area nodes could belong to different factions (generic at first, expanded into races/behaviours as a stretch goal)
Between each stage, factions spread and capture systems/worlds.
Basic top scrolling shooter mechanics
Player ship spawn + movements
Enemy wave generation
Basic enemy AI, (Move pattern, fire pattern?)
Player ship health
We can make a place holder mechanic for the core game where generic collected loot (metal or minerals) is traded for ship mods between levels at a store.
(If you have ever played “Raptor: Call of the Shadows”, sort of like that)
Focus on developing the shooter sub-game first as stage 1 goal, start overworld sub-game as stage 2 goal.
I have to admit that Raptor will be a huge influence for me with regards to the shooter portions as I played that game far too much growing up.
I am imagining That mechanic (Can take dammage before dying, weapons purchased between rounds with loot gained during) in space with the addition of an over-world to tie things together.
I would suggest we make the overworld game a stretch goal. Let’s focus on our vision (Raiden X RPG) and get that working, then we can start pulling it in different directions.
How about a slight extension of your core game:
Player ship spawn + movements, enemy wave generation, basic enemy AI
Generic loot (minerals/whatever) from killing enemies
Upgrade your ship between levels in the store
My suggested changes (what do you think?)
Simple bosses at the end of each stage (even if it’s just a giant version of an enemy)
Stuff levels up as you use it. Hit more stuff => weapon levels up. Absorb more hits in shield => shield levels up. Direct hull hits => hull levels up.
A simple pilot with three basic skills, and you can allocate skill points (one per level up): agility (how fast you move), power (multiplier to raw damage, eg. 1.1x), defense (multiplier to shield/hull).
The simplest thing IMO is generated levels. Details aren’t important, but two things are:
You have a number of “basic” enemies (eg. 7 types, perhaps with slightly different shots, speeds, etc.)
You have a way to tweak them, eg. increase speed, increase damage, to create variation
I don’t know, I’m not convinced that it sounds fun. The only novel thing is levelling up parts, and levelling up the pilot. We can drop bosses for now too.
I spoke to Abrar about this on Google+ for a while. We agreed that “let’s just go with a simple 2D shooter like Raiden-X for now, and integrate the awesome unique gameplay twist later.”
Ideas we talked about (together and here on this thread):
absorption: absorbing enemies (possibly researching their weapons first) and using them
modular weapon upgrades eg. weapons have parts you can upgrade (eg. single shot barrel => triple-shot barrel)
weapon/ship mastery (skill level goes up either with use or with high accuracy)
I am still trying to think of some sort of novel mechanic we can add.
In the meantime am playing around with pygame, learning how it handles sprites and collision detection.
It looks fairly simple so I should have a decent enough handle on it when it comes time to write the engine for the core game.
I was thinking that we could sample the sprite images/positions to generate a mask as integer arrays (thresholding the spite image then storing the resulting mask in the main mask as an integer reference to the parent object occupying that space) so we could rapidly check collision detection frame by frame by just checking that the mask element is blank with each write (Eg each frame, a new mask is generated, if 2 objects attempt to write to the same element, a collision is detected and processed)
Doing so should create a cool collision detection system based on the actual pixel locations rather than just clumbsy box-collision detection.
This however turned out to already exist in the pygame library. So I am learning to use that.
The pygame version also seems to reference what group the parent sprite was part of (Eg Friendly, enemy, bullet), accepts flags for which sprites if any are despawned on collision and possibly references a callback function to execute arbitrary code on the event of different collisions taking place.
I learned the hard way (over multiple engines) that per-pixel collision detection is very complex (check if two rotated, scaled sprites collide) and usually unnecessary. AABB (non-rotated bounding boxes) is extremely fast and cheap, and usually good enough.
If not, other approximations are usually used (eg. circle). Some engines allow you to define polygons, which is okay if they’re convex and don’t have holes.
Unless we really have a need to do something different, I would trust the PyGame libraries to work (and work well) and we should leverage them. I’d rather spend the few hours I have writing the game code than writing and testing collision checking code.
Speaking of testing, I’ll look into unit testing PyGame code. Let’s see how far we can go. PyGame has its own suite of unit tests, so I’m pretty optimistic that we can write testable code.
I created a new repository here. I couldn’t make a new “MGDG” or “DGMG” organization because those user names are taken, so I put it under “Deen Games Prototypes.” We can transfer the repo later inshaAllah to a more suitable home.
Here’s the MVP WBS. Please leave comments if you add/edit/delete anything. I would like to manage it so we can coordinate better. It’s very basic: the focus is “get a basic 2D shooting boxes” thing done and then we figure out and prototype what makes it fun/unique.
MVP = Minimal Viable Product = cut everything you can until there’s something you can’t cut because there’s no game without it. That’s MVP.
WBS = Work Breakdown Structure = list of absolutely everything we have to do.
Please assign yourself tasks. Please fork and open a pull request (instead of directly committing) and wait for one other person to review your code. (If this becomes a bottleneck, we’ll change the process.)
Questions? Comments? Excited statements of motivation?
