As much as I like some of these ideas like the dungeon crawling with genetic persistence between games, I think our first project in a genre should focus around getting some sort of game engine set up for that style game with a very simple game built on top of it.
That way if we start a new project later in that same genre, we can branch off from that original project as a starting point so that we can focus more dev time in developing better assets and much more complicated mechanics.
Eg if we decide we want to make JRPG then our first project in that area can focus on producing the engine and data structure, writing the basic combat mechanics, overworld mechanics, dialogue tree mechanic and item system Mechanics while making the game itself as barebones as it can be. Our 2nd attempt at a JRPG can use the core prototype from the first game as a starting point, cloning the source code, so we can then use the following month developing good assets, interesting mechanics and storyline.
The problem with engines is that you never know exactly what you need. You end up building abstract code that does stuff thatās not even necessary. And at the end, you donāt get a game out of it.
In my limited experience, reusing code is one of the biggest things that slows projects down. You can often learn from your mistakes, start fresh, and write better code faster.
I agree that we should build something simple. The pokemonz game is actually very simple ā the hard part is building the list of creatures/powers/evolutions.
Also, for Pythoners, I added a build.sh script to that repository so you can build a single self-standing executable. Can someone test it on Windows?
So I have played around with Pygame a little bit and I seem to have made a thing.
It isnāt a game yet, as there are no controls, no fail-state and no objective. But it might be a game one dayā¦
The thing was made with the goal of seeing what I could do in a few hours, so the code is somewhat rough and convoluted.
Basically the thing spawns a grid and a group of bugs that move randomly around it.
On every movement, each bug has a probability to split into 2 bugs. The probability is highest when there are less bugs in play.
If 2 bugs collide, they explode causing both to despawn and that section of the grid to be destroyed.
Bugs move around the grid randomly, but only to adjacent locations that are still intact.
I can maybe turn this into a game by spawning a player controlled circle, allowing the player to move with keyboard commands. The player constantly moves in what ever direction was last specified by the player (Eg āSnakeā controls), points are earned for the duration the player survies for and the game ends if the player comes into contact with either a bug or destroyed section of grid.
Existing bug: game occasionally crashes when bugs despawn - No such element in list error.
To be added: Player & Game elements
Timer based threading for simulation timing and frame rate.
Iām impressed with how quickly you put something together, mashaAllah tabarakallah. Thatās a testament to your ability to learn and code, and perhaps also to PyGame being easy to setup and get started with.
I personally have almost zero experience with Python, and maybe thatās why I found your code hard to follow. If I may suggest: could you use more descriptive variable names? buglist is cool, but vchk, SX, et. all threw me out completely. I have a very poor idea of what these variables are for.
I personally thought the Game Of Life had a lot of potential in being a real game, eg. you spawn those things that move and have to collide/disrupt existing patterns. Your game reminds me of that ā a kind of simulation game.
For my variable names and algorithm:
SX, SY and Res refer to my screen variables - Screen-size-X, Screen-size-Y and Grid Resolution.
- Adjusting these variables will adjust the size of the game window and grid.
- Adjusting Res alters the number of pixels between each grid co-ordinate. If you drop this down to 10, you will have the grid size, increasing the number of grid locations by a power of 2.
- Adjusting screen size but keeping resolution constant will also increase the grid size as the grid will expand to fill the screen at the given density.
Framerate and FrameTime are not yet implemented
- Pygame has a function that appears to handle threading, by declaring that a function should be periodically run at a set period. FrameTime is generated from the FrameRate which should be set by the coder.
- Using these functions I should be able to set the simulation to process at a set speed independent of the display framerate while throtteling a set frame rate to slow the game down under lighter loads or start skipping frames if things are getting too heavy to render at the set framerate.
Buglist is a list of āBugā objects.
- Each āBugā object contains the variables X, Y and vector
- X, Y are the screen positions of the āBugā
- vector is an integer 0-3 indicating the current direction of movement.
I can re-work this to make vector reference a dictionary of cardional directions which will simplify movement processing later.
Within the āBugā objects class, I have 2 functions
-
init is called when a new bug is spawned. It accepts the variables X,Y,and Vector, being the attributes of its parent āBugā that is spawning it.
-
This function spawns a new āBugā with the same co-ordinates of the parent, then randomly selects a new vector and verifys that the new vector is legal (Not obstructed) and differnt from the parent.
-
I added a timeout here so that after 10 failed attempts to select a new heading (Eg the spawn location only allows the bug to move in the direction of the parent and immediately collide) it gives up and just lets them explode rather then getting stuck in an infinite loop.
-
The Variable here āVchkā refers to Vector-check, which is a flag indicating if the chosen vector is legal. It is set to start with, and cleared if the vector has been judged to be legal. If after checking, the vector is not approved, the process is repeated.
-
The class also contains the function update()
-
bug.update() is called to update the bug movements and positions,
-
Vector is evaluated to determine if movement is horizontal (0,1) or vertical (2,3). The value seperated by range to determine axis then shifted to adjusted to equate to -1 or +1 which is then added to the relevent object position variable.
-
The bug position is quickly evaluated to see if it is currently located at a grid intersection, if so a new vector is randomly chosen using code copy-pasted from the Init function.
-
The extra line in the position update self.(X/Y) = self.(X/Y) - (self.(X/Y)%Res) is a bug fixing measure as some bugs were spawning slightly off the gride. meaning that collisions and heading changes are never processed. This code clamps the bugs unchanging position (X or Y) to the nearest rail.
def drawgrid() is my main drawing function
- This function draws on a global list that tracks the current grid condition across the map Grid[X,Y]
- Grid[X,Y] is the size of the Screen / Resolution and all initialised to 1 except for the boundry locations to keep the bugs from escaping the map.
- This contains a nested for loop that works its way though a 2 dimensional list Grid[].
- Each time a grid location is evaluated as existing, 3 shapes are drawn to screen at the indicated location (co-ord * Resolution to convert grid number to physical locaiton on screen).
- Drawn objects are a circle, and 2 lines (Vertical and horizontal)
- This function used to also work through the bug list, drawing their positions to screen, but for some reason drawing the bugs here resulted in a massive slowdown that is somehow avoided by drawing them in the main function.
Finally in the main function
- The initialization code generates the Grid matrix, starting with setting them all to 1, then working around the boundries, clearing those locations to set the external walls.
- Pygame engine initialization function is called
- Screen is spawned using the set screen size parameters
- The initial āBugā is spawned in the central location by calling buglist.append which adds a new bug object to the list. Adding this object will call the init function described earlier
The main gameloop starts here:
-
Pygame checks for events such as player input
-
Shutsdown the game engine if the player calls for the game to end
-
Can add player input handling here
-
The previous screen image is cleared using background.fill(), without this the bugs will leave behind a trail, clearing each frame will result in only the current locations being displayed.
-
Background is now redrawn so that the bugs will be drawn over a fresh image when they are processed.
-
We then start processing each existing bug by working through the current buglist from start to finish.
-
For each bug in the list, we call the bug.update() function described earlier to update the bug positions and heading as needed
-
Each bug is checked against every other existing bug (except for themselves) for collision detection, both bugs are in the same location, both are removed from the list effectively despawning them and the local grid location is cleared from the Grid[] list, effectively removing that location.
-
The variable here bugcount is increased when a bug is spawned and decreased when it is destroyed.
-
Each time a bug is updated, there is a chance here to spawn a new bug, The random value range here is scaled by the number of bugs in play, effectively dropping the chance of spawning new bugs as the population grows. (And I have just rubber-ducked myself and I now know why the bugs were spawning off grid earlier and why I need to clamp them to the grid. This statement should exist where a new vector is selected rather than on every step.)
-
Finally the drawn image is drawn to screen by blitting the background image against the screen object and flipping it (Write to screen).
All in all: This development took about 5 hours across 3 days (1-2 hours/session) including development, polishing and bug-hunting.
Thanks for the extremely detailed response. Iām glad you rubber-ducked 
I wasnāt asking you to post an entire explanation (thanks and sorry for that). I was hoping you would actually, if/when we collaborate, choose better names and perhaps more judicious use of comments (eg. calling it direction instead of vector would have gone a long way).
I would have renamed vchk to isDirectionFreeCheck, and SX/SY to screenX and screenY. IMHO that would have made it much more understandable.
@Severok I juts had a lengthy chat with @AbrarSyed on Discord. Are you okay with the RaidenX idea for the first project? Weāre both sold on it, and it looks like just the three of us right now.
Noted. I started that responce just clarifying the variable names, but it kind of got away from me.
I abrivated the variable names to save time retyping them while coding as my IDE was being difficult, so I wrote about 90% of the code using VIM in my terminal window. In proper collaboration I will attempt to use more detailed variable names.
Are you okay with the RaidenX idea for the first project?
A scrolling āBullet-Hellā shooter with RPG elements? Iām im.
1 Like
āIām imā - The ever so wise @Severok
1 Like
Iām im
A statement that is technically true yet misses the mark entirely.
With that level of oversight, I am confident in what I have to contribute to this project.
1 Like
Joining inā¦
Iāve always wanted to develop a game. Like everyone Iāve got a bunch of ideas.
Relevant background:
I wouldnāt dare to call myself a coder. I was really into coding in my younger days. I taught myself gwbasic at age 9 by looking over the shoulder of my brother. Made a telephone directory with it and moving text what not. In grade 9 was exposed to Turing and made a snakes and ladders game. Exposed to VB a couple years later and made a 2d, 2 player shooter game. I did go to Uni for com sci but ended up dropping out after first year and started working.
First job was actually working for a company that ran after school and summer school camps teaching kids how to make video games. Company is still around www.realprogramming.com.
After this, I havenāt touched code.
So Iām eager to learn and do what I can to contribute.
Iām a business guy and a sales guy. I know how to make a product make revenue. Iām an entrepreneur and own an IT reselling company which I started up from the ground. So I offer this skill set too biāidthnillah
I would appreciate any guidance, apps, tools that you guys can recommend me towards to learn and such. In another thread I was talking about how steam seems to have tools on sale to make games. Iām an iOS and Mac user and would love to begin this journey by making a simple game that I can play on my iPhone.
1 Like
Thatās interesting. I didnāt know that about your history ā¦
There are tools, but nothing lets you publish for free to iOS. You can try Unity. Itās more geared to 3D, but itās making major inroads to 2D as well.
There are other options, like Game Salad, Corona SDK, and Construct2, but Iāve never used any of them so I canāt really vouch for any of them.
If you wanted to get back into coding, weāre looking into Python, which is supposed to be pretty easy to learn.
Hey @AbrarSyed @severok, @asad3ainjalout and I had a chat about licensing on Steam just now. He likes the GPL license (I suggested MIT initially).
Are you guys okay with GPL? GPL means āthis work is open-source, and if you reuse any of this code, you must open-source that thing that you just built.ā The only down-side I can see is that if we want to commercialize something we built, and/or we want to reuse parts of our code, that forces us to keep it open-source (which makes monetizing very, very difficult).
Alternatively, heās okay with LGPL/MIT, which allows people to reuse code in closed-source projects.
Thoughts?
Alternative to PyGame is Pyglet, which is more āOpenGL-likeā.
Technically I was asleep, but Open Source is cool with me.
It would be ironic for a Muslim Game dev project to work with pyglet (Piglet)
Salaam team, I am back.
How are you all doing?
When are we looking to kick this project off?
Is everyone still in?
Waāalikum as-salaam. I think weāre shooting for August to start.
- Tools: PyGame
- License: open source (MIT?)
- Game: Raiden-X like 2D space shooter
The only thing I think weāre missing now IMO is @XizorGetspeedās contribution ā where/what would you like to help out?
@AbrarSyed also created a #gamedev text channel on Discord. Iāll be lurking around there.
Awesome.
I have been trying to think of mechanics to add.
The more I think of it I would like to add a set of hot keys allowing the player to quickly redirect and balance power between Engines, Weapons and Shields.
Eg:
Balanced: Stock ship stats.
Shields: Shield strength +++, Movement speed --, Weapon damage ā
Engines: Shield strength --, Movement speed +++, Weapon damage ā
Weapons: Shield strength --, Movement speed --, Weapon damage +++
This could help give the game a slightly different feel between Tactical/Twitch gaming as differnt settings could give players advantages in different situations and players have to make snap decisions of which stance to take to gain the best advantage.
Eg:
A huge wave of ships appear spraying the area with shots.
Player shifts power to the engines boosting speed/agility allowing the player to weave though the shots.
Player misteps and gets cornered, knowing that avoiding the shots is unlikely player shifts power to shields.
Player ship struggles to a crawl, but the shields flare into life as the wave of shots passes over the ship.
As the wave of enemy ships break from their attack run, the players ship drops shields and transfers that power to weapons, gunning them down with a vengence.
I also have 2 more ideas for games which I might submit for future projects.
1 with turnbased tycoon multiplayer game which might be achiveable using pygame with an additional telnet module
1 a SRPG that might be achiveable with RPG maker an a heap of heavy scripting (EG writing a new battle engine)
1 Like
I like your mechanics ideas.
Do you guys want to start in September? Something came up for August and I canāt lead this any more.
Or do you prefer a slow-start in August and ramp up to full speed in September?
Still ready and willing. How are things looking for September?
I can possibly lay some groundwork in August for sprite spawning/movement and a parallax scrolling backdrop.
For the moment I have been researching storyline components for a D&D campaign and designing some electronics.
