Hello everyone. I've mentioned this in passing in IRC, and since the winter semester is starting soon, I figured it would be best to make a topic about this now.

I am making a Lemmings-like game for my final college project!

The name of the game is Tech Mechs! (tentatively) The game follows the adventures of the Tech Mechs: intergalactic explorers who need your help reaching the end of these planetary obstacles! It plays like Lemmings: the Tech Mechs come out of their base and need to reach their rocketship to blast to another planet. They wander around aimlessly, and you give them the tools they need to succeed.

How will this be different from Lemmings?

Although this game will draw many inspirations from Lemmings, there will be many differences.

First, I want it to be more contained than what we currently have. Ideally, I'd like this game to allow for playing packs/levels, creating levels/packs, creating/modifying graphics sets, and sharing your levels all in the same program. I feel like this will give users a much better, more intuitive, and simpler experience than what we have for NeoLemmix. (Lix does a pretty good job on doing this)

Not only that, but I'd also like to incorporate multiplayer into the game. Not competitive multiplayer like Lix, but cooperative multiplayer, allowing for highly complex puzzles requiring multiple people with different skills working together to solve. Each player would have their own Tech Mechs that only they can assign skills to, as well as a different skillset from the other player(s) and a different entrance. All players would share the same exit though. The idea of multiplayer is to encourage people to cooperate and solve puzzles together.

I also think having a level/graphic set database would be really cool, so people could design levels and new graphic sets, post them online, and have other people easily find them, similar to Super Mario Maker. This would negate the need to manually send packs online like we do on the forums, but would also be very complicated!

Finally, a lot of the skills will be different from the ones in Lemmings and Lix. A few skills I feel would have to be brought over from Lemmings, because they are so indispensable.

What will the final product be?

My final project for school will be a beta version of this game. Hopefully, most of the features will be completed in a rather crude manner, and I'd still need to polish it a lot and incorporate new features into it.

When the game is finished, I'd like to sell it on Steam, provided I think it is high-quality enough. The game would ideally attract both the people who grew up with and loved Lemmings, as well as introduce new players to the genre!

Will every level be outer space themed?

Absolutely not. Like Lemmings, this game will have graphic sets. I consider each graphic set to represent a different planet or celestial body. There might be a planet full of huge trees, a planet with red rocks everywhere, or even a planet with giant video game cartridges everywhere! The possibilities are endless, and are no different than Lemmings graphic sets; the ones I create initially may be more space-themed, but that's mostly just to give my game a "theme" for my project evaluators.

What tool/skills will be in the game to assign to Tech Mechs?

I don't have the list finalized by any means, but I'd personally like to incorporate the following skills:

Builder
Yeah, this is one of those skills that really cannot be missing from the game, due to its immense flexibility, power, and overall indispensability in solving puzzles. This will function more or less identically to its Lemmings counterpart.

Driller
Make no mistake, this skill is a basher, with its horizontal terrain destruction, but this one will quickly and smoothly carve its way through walls, more similar to the shoveler in Lix.

Jackhammer
It's the digger, digging straight down until there is no longer terrain under you.

Miner
You know what this does. I may rename it if I can think of a more futuristic thing to accomplish the same task.

Land mine
An interesting take on the bomber. Using this causes the Tech Mech to place a bomb on the ground and continue walking. The bomb blows up a few seconds later taking the nearby terrain with it. This way, it combines the best of both timed and instant bombers!

Caution sign
An alternative to the blocker. This causes a Tech Mech to place a sign right in front of him. Any Tech Mech who reaches the sign will see it says Caution, and will turn around. If you destroy the Terrain under the sign, it will fall down, and Tech Mechs won't be affected by it.

Grappling hook
Like the roper from Lemmings 2, using this allows a Tech Mech to shoot a grappling hook in a direction of your choice, creating a straight line from where they are standing to the first terrain it touches. The game will pause until you select where you want to shoot it, and the range of the grappling hook should be marked by a circle. A much quicker and less tedious alternative to builders.

Laser blaster
Don't get nervous, this tool improves on the Lemmings 2 version by allowing you to shoot it straight up, left, or right. The laser blaster shoots through a single piece of terrain, ending if it breaks though, reaches the border of the level, or hits steel. Like the grappling hook, the game pauses until you choose a direction to shoot. This will allow you to destroy terrain at a distance, and quickly enough that Tech Mechs won't turn around in the tunnel while you're destroying it.

Hover boots
Functions like the floater, slowing a Tech Mech's descent twice as much saving them from fatal falls.

Energy jolt
Using this on a Tech Mech energizes them, making them move and perform skills twice as fast!

Anti-gravity boots
Something I've wanted in Lemmings for a long, long time. This reverses gravity for a Tech Mech, making them walk on the ceilings and perform tasks upside-down, allowing for tons of more puzzle potential! Using another pair of anti-gravity boots brings them back to regular gravity.

Timefreeze
Use this on a Tech Mech to freeze them in timespace. They stop WHATEVER they're doing until you click on them again.

Magnet boots
Lets Tech Mechs walk up walls, but not ceilings. (Anti-gravity boots are for putting Tech Mechs on the ceiling) Skills can be assigned to them while they are walking up walls.


Right now, I don't have all of the programming knowledge to implement all of this, specifically the wireless multiplayer and database for level/graphic set creation. My professor has suggested using a Restful API for making the server for multiplayer or even trying to make a serverless cloud for multiplayer, but I have no clue how to do either of those things. If anyone has worked with those or has alternative suggestions for how to send data across computers on different networks, than please let me know! Also, let me know what you think and if you have questions/suggestions!

Oh, I really love the concept, especially the skills! I wish you the best of luck and hope I can one day try this game out.

My advice (without having gone to college myself, so maybe useless) is for; as of right now; make it as simple as you can. There will be plenty of time to continue this project after graduation and make it as big and complex as you want when your future no longer depends on it. Simon and namida/Nepster can take any risks they want because the only wrath they face is us   ( and won't lose funding).

Focus on making the game look really nice and run smoothly over puzzle design. While I don't think you should neglect puzzle design; I would bring with it at least a couple of nice puzzle levels (either new ones are maybe your best from Sublems or whatever) as demos; but You want to prove that you can make a working, efficiently running program over everything else (I'm guessing?)

Try to remove major game breaking glitches; but obscure glitches you might want to not bother caring about: I'm talking about things that might crop up like the old sliding glitch. This glitch was so obscure that many people (including myself) never discovered it on my own and even then; it was so difficult to pull off; I'm guessing that in the brief time your professor's or whoever test out this game aren't going to find these kind of things.

Now I know nothing about your class but even so; while this game sounds awesome; it sounds like quite a tall order for this project. I don't mean to discourage you but if you start struggling maybe cut some major things out to focus on the other major parts; like multi-player or the database. Don't get me wrong; those are excellent ideas that I support.

If your game goes to Steam I'll definitely support it!   There's greenlight or kickstarter you could use.

The new take on the blocker and bomber sound nice. I'm totally ok with adding new stuff and making a new spin on the Lemmings Genre. For sale on Steam I'm guessing there's a host of things to consider; and things you ought to add or think about for the game to get more people interested in it. I would do plenty of research on that before attempting.

Yes, this is very ambitious.

Definitely focus on the essentials. You have half a year and no typical problems of existing Lemmings software designs burned into your mind yet. D Lix with ~25,000 lines took 2-3 years to acquire 95 % of C++ Lix's features.

I've grown wary of pure movement skills for our existing engines: Skills that affect only the movement of the assignee. I encourage skills that alter the terrain, or that directly affect lemmings other than the assignee (blocker, batter). I'd love to see more creativity in these two categories.

But if you like pure movement skills, that's fine, it'll be a different flavor of skillset. I know mobius likes pure movement skills, too. Maybe pure movement becomes better design in cooperative networking even, you don't step on other people's toes so much.

There's always a side benefit behind larger projects. I've learned Lua in 2002 and wrote simple scripts that ran inside a host game. I began C++ Lix in 2006 to build a standalone program, and, as a side benefit, appreciated strict static typing and how that helps with refactoring. When I was forced to switch from Allegro 4 to 5, I ported to D to make Lix easier to maintain, and, as a side benefit, understood deeper ideas behind object-oriententation, functional programming, and the joys of automated testing. None of these side benefits were particular to C++ or D.

Watching software grow from scratch is exhilarating. Please keep us updated every couple weeks at least. I'll be happy to discuss technical ideas!

-- Simon

With just half a year at least for the "school project" phase of things, I think it'd be good to aim first to get a demo consisting of just maybe 1-3 playable levels and a small set of skills and objects implemented (again maybe 1-3).  How long it takes to get to that point will help you determine your next steps afterwards.  It may be that things took longer than planned and the remaining time you had only allows you to add a few more levels or maybe 1-2 more skills.  Or you find yourself with still a few months left and can tackle larger features like the beginnings of a level editor.  Of course, you are free to continue to work on completing all the rest after the official school-project part is over.

Multiplayer is probably good extra credit for the technical challenges, but I suspect will be more challenging to both code and test than the level editor.

Simon will surely be invaluable in all manners of advice from design to programming.  Lix is very much made from scratch like your project would be, and he has put a great deal of thoughts into both game design as well as the design of the program itself.

Are you a good artist?  It may be worth considering trying to borrow as much pre-existing artwork as you can from any appropriately licensed sources to save time, at least for the school-project portion of it assuming the focus is more on quality of programming than quality of artwork.  Obviously for the eventual final product you will want to be less derivative and crude with the graphics, and its quality will certainly be very important, but for the beta and demos you can probably get away with things being a bit cruder.  Maybe the animation is more choppy with low framerate (by eg. repeating the same frame multiple times), but functional enough to allow the game to be played.  Maybe you start off with very basic shapes like squares and rectangles for terrain and only later expand the graphics to something richer, varied and more complete.

Anyhow, good luck and hope you have a lot of fun and learn a lot out of it!

git clone https://github.com/colorfularty/Tech-Mechs

-- Simon

Thanks Simon for posting the GitHub link. For those who don't know, GitHub is a website where you can upload code you make as well as revise it (and revisions are saved if you want a previous version). I will periodically post updates to my program to implement new features.

As of today, I have made a very simple test level that is solved automatically to program the most basic parts of the game (like walking and falling physics). It is still extremely crude, but anyone can download the files and run the code, but you'll need Python 3 and the Pygame library to run the code.

Made another update on GitHub, implementing a crude version of the first skill: the driller.

Also, there is a bug somewhere in techmech.py that causes a left-facing Tech Mech's image to flip to the right-facing image despite them moving to the left. Ideally, the code should flip the Tech Mech's image only if they turn around, or if a right-facing image is loaded onto a left-facing Tech Mech. Anyone who wants to try finding the source is welcome to, but I'll try to figure it out after taking a break.

Cache your images once you load. Do not generate sprites every time activity changes (you load from disk) or direction changes (you allocate new flipped texture).

Choice of sprite can then be a function of activity and direction. You don't have to keep mutable pointer to sprite in the lemming; instead, choose sprite only during drawing. This way, you avoid unnecessary state, which is the source of the bug: Your class allows right-facing sprite on left-directioned lemming.

Document what the return value of act() is supposed to mean.

-- Simon

Good suggestion. The return value is True by default. If it returns False, it means the Tech Mech moved offscreen, and thus will die. Dying is handled by the main program because it needs to remove the Tech Mech from the tech mech list only accessable to the main program.

Made another update. I added a basic jackhammerer skill, which functions similar to the digger. Left clicking assigns a driller and right clicking assigns a jackhammerer.

Your act() is growing too big. You should split it into understandable chunks.

Whenever there is high-level structure behind something, the code should be designed such that the structure is immediately obvious to the reader. The one long method doesn't convey such intention; unless you read it all, you must fear that anything might happen at any time.

-- Simon

Yeah, this act() calling shorter methods is better.

The grappler takes 2 clicks, one to select mech, one to fire rope. You've chosen to make the first click purely part of the UI and not have any physics. Therefore, as you have correctly implemented, the first click will have no logic in the mech's physics. All the code in grapple() is for after the second click.

Since the mechs are responsible for rendering themselves, it is conceivable that the mech class still gets some code for what happens after the first click, to draw the grappler circle themselves. Or maybe they render themselves in a different color while the mouse is hovering over them. This would not violate the previous paragraph about physics. My hunch is to put such code where we can minimize the information that must be passed between the classes.

Fun questions: Should the user be able to cancel grappling at any time between the first and second click? Should falling cancel grappling? Should the skill be deducted from the skillset only after the second click? In multiplayer, can teammates share a skillset, can player A's second click for grappling cancel player B's first click for grappling?

Whenever a mech exits, the sprite of the oldest remaining mech will flicker for one frame. Do you prefer github issues for issue reports?

You have 3 different skills now and function keys to toggle. Maybe it's a good time to implement UI for the skills soon since you want skill UI in the finished prototype?

Your hunch for networking was to have the server run a lot of physics logic. This is different from Lix, and therefore I can't advise whether it's urgent to funnel all singleplayer skill assignments through a replay first, then compute physics from the replay. At least you're aware of the rough picture and can postpone the decision.

The downside of Lix's client-only physics is that the server cannot ever keep track of won games, statistics, ..., and, scarily, doesn't even know whether a game is running or not. The server merely waits until everybody declared ready, then sends the start-game message to all clients. Looking only at the protocol, Lix clients are free to send ready messages during play, or skill assignments during lobby. They merely don't do that because the client UI doesn't allow it.

-- Simon

Great questions posed Simon. I'll try to answer them all.

First, implementing the skillbar is the next thing on my TODO list for Tech Mechs. Once that is in place, it will become much more user-friendly and it should be relatively simple to implement.

Regarding the first roper click not affecting the Tech Mech class code at all, I did that specifically for the point you brought up below: trying to minimize the information passed between classes. The circle showing the roper range must be drawn after all of the Tech Mechs are blitted to the screen, so having the Tech Mech draw the circle to the screen in a Tech Mech class method would result in the circle overlapping some tech mechs, but not others. This is undesirable behavior, so I draw the circle in the main.py file after the tech mechs are rendered. I created the grappler variable to keep track of which Tech Mech has the grappling hook (roper) skill assigned to it so it doesn't have to iterate through every Tech Mech and I don't need an extra class variable in the Tech Mech code to keep track of if the Tech Mech has been clicked once by the grappler skill. This code structure is not finalized, but I think it's efficient and simple to implement.

Regarding when the grappling hook skill is consumed, I plan on only consuming the skill after the second click has occurred. The user will be able to cancel the grapple either by clicking on the grappler skill in the taskbar again or right-clicking.

In multiplayer, people will not be able to affect each other's grapples. If one player clicks a Tech Mech to assign a grappling hook, the other player will not be able to make said Tech Mech grapple, as each player will have different colored Tech Mechs and potentially different skillsets.

While my initial plan was to have the server do all the physics computations, after talking with you in IRC, I decided to change it to each client computes physics and then sends the replay assignments across the server to the other player(s). This would be pretty simple to implement compared to making a large server class with duplicate physics code.

Also, after talking to my supervisor yesterday, and he gave me some good suggestions on how to implement a simple server in my program. I'll research those methods and make a plan soon.

Thanks for the continued interest in my project!

I just pushed changes to GitHub. The game now has finite skills, a skill panel, simple map scrolling, 4 skills (including an anti-gravity and roper skill), and some simple animations. Once the game starts getting out of its beta graphics, I'll post a screenshot to the top of the topic. As always, feedback is greatly appreciated!