Lemmings Forums
Other Lemmings Projects => Other Projects => Topic started by: Colorful Arty on December 22, 2017, 03:37:12 AM
-
(https://i.imgur.com/s1TEkOI.png)
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! :D
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! :D
-
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. :D
-
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. :P Simon and namida/Nepster can take any risks they want because the only wrath they face is us :P ( 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! :thumbsup: 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! :thumbsup:
-
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! :D
-
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! :D
-
The main module is getting rather long.
You have these lists of variables that are grouped by comment, e.g., # level variables. And you have behavior associated closely with these variables, executeGameFrame and handleGameEvents, whereas these variables are never used outside of these functions.
Consider creating a class from these data and behaviors, and move this code into a separate module. # level variables is already a hint about what abstraction this class will capture.
Some comments can be replaced with better identifier names. E.g.,
# handle the user-related events like mouse clicks or keyboard presses
handleGameEvents()
Why do you explain what the called function does when it's called with zero arguments? If you don't believe that handleGameEvents() is clear enough, rename handleGameEvents such that it will be clear.
If you've moved this code to a class that captures the abstraction of playing a single level, then this will probably be a method of that class. This is excellent for naming methods, you can omit "Game" from the method name because the class will already tell us that this method deals only with playing the game.
TechMech.wasClicked assumes arguments to be map coordinates, but it's called with mouse coordinates. As a result, once you scroll such that screen's top-left no longer coincides with map's top-left, we cannot click exactly on mechs to assign skills.
Which of the two modules, main or techmech, has the bug? Is it possible to prevent calling the method with wrong data (ideally static error, next best is runtime throws)? If it's not possible to prevent the bug by design, is it at least possible to define the method such that, once we call it with wrong data, the calling code looks wrong? Or is convention really the only solution, in which case we should document it glaringly?
-- Simon
-
Excellent catch on the mouse clicking bug; I will make patching that top priority right now.
I agree the main.py file is getting a bit long. Some of this is unavoidable, as the SCREEN variable, and any variables relating to the graphics library initializer must be called by the main file. I may move some of these to a different file, but the problem is getting access to these important game/level variables quickly from the main file.
-
I finally got a walker animation that looks fluid and pleasing! I'm quite proud of it! :D
(https://i.imgur.com/1duP4RL.gif)
-
Awesome, looks like it will walk faster than Lemmings, Lemmings have evolved!
Good work Arty, keep it up :)
-
Just updated the "game". Lot of bug fixes and animations added. I also added a poll for people to vote on what I should make next.
-
Latest version is on github. Caution signs and land mines are now skills. The test level now uses lix graphics, and there is a title screen.
-
I know progress on this has been slow for a month now, but the reason for this is not that I wasn't working on it, but because I didn't want to push the level editor until it was functionally complete! You can now create your own levels, save them as .txt files and then play them! My Lego tileset has also been included in the game now!
My next step will be working towards getting basic wireless multiplayer to work as well as increasing level editor intuitiveness and maybe even implementing more skills!
-
I tested the current version of Tech-Mechs as of the date of this post.
One non-inherent point: The files in the github repo don't seem to be complete. There is missing pause.png and "end level.png", which leads to several crashes (e.g. upon opening a level) and level.py/skill.py don't seem to have the new skills "Energizer" und "Magnet Boots" defined, which crashes the current Lego level, which has these in it.
It's nice that there is now pause and a possibility to end the level prematurely in single player and that an end of level dialog gives feedback upon your results. Although you can't see the requirements beforehand (apart from looking in the editor)?
I've tried the multiplayer which generally worked well but the window of player 2 froze in most occasions upon level finish. I think you have no indicator which are your Tech-Mechs unless you try to assign a skill?
It's a bit odd that you have so much free space and the level is in the upper left corner. The sprites of the Tech-Mechs have block boxes around them.
-
I read all the posts: very interesting. :)
-
I just committed what I hope is the last updates for the beta version that I am submitting as my final school project (Download at https://github.com/colorfularty/Tech-Mechs (https://github.com/colorfularty/Tech-Mechs)). For those who are curious, the game now has the following features:
- Fully functioning single player
- Fully functioning cooperative 2p multiplayer, although the server is not up and running 24/7. Please let me know if you want to try out the multiplayer, and I can run the server on my VPS
- A functioning level editor that lets you create single player and multiplayer levels
- Customizable hotkeys
- Two graphic sets: my lego tileset and a special graphics tileset
- A few music tracks, all of which were taken from modarchive
- A few simple sound effects, used when certain skills are assigned
- 8 skills: including the magnet boots, energizer, cautioner, detonator, jackhammerer, driller, grappler, and gravity reverser
To those who have played the various builds I've made, thank you very much, and thank you for all feedback, whether positive or constructively negative. If you encounter any serious bugs in the code, PLEASE let me know ASAP and I will patch it as quickly as I can.
I'm already making a list of things that NEED to be done, and things I want to get done for future updates. I've divided them into categories: small things and large things.
Small things that need to be done
- Improved multiplayer game interface. Specifically, right now once you click multiplayer and the server is running, you get stuck in a wait screen until another person joins. Ideally, you should be able to leave the multiplayer lobby at any time to go back to the main menu, and the server should react accordingly.
- Improved sound effect handling. Right now the sound effect handling is meh at best, with tons of bugs and minimal sounds in general. Ideally every sound effect should stop naturally when appropriate and should not overwrite other sound effects currently being played.
- A "get objects" button in the level editor. Much like in the NLEditor, you can toggle between terrain and objects being displayed in the panels. Right now, only terrain is displayed, so objects still have to be inserted and modified via hotkeys.
- Main menu music. The menus feel a little lonely without some awesome music playing in the background.
Big things that I want to do
- Better graphics. The graphics are passable at best, but look far from professional quality. In order to improve this, I'll either need to hire people for this, or take some classes/tutorials to improve my artwork.
- More/better animations. Many skills have no animation to them, especially the cautioner and detonator. I'd like to change that in the future, but it'll be a decent-sized job.
- Custom music for the game. Mobius has graciously agreed to help me with this, as he is far more talented than I at that. But custom tracks take time and fine-tuning before it gets done.
- More graphic sets. Specifically graphic sets that look good and are very flexible, like the original and Oh No graphic sets that have limitless possibilities for what can be made with them
- More skills. I have ideas for putting in a builder and miner skill, as well as a laser blaster, flamethrower, and (possibly) hover boots skill if I end up making splat height a thing.
- More objects. I crudely put water in the game, but right now it just functions like instant death, and I'd love to add in special shorting-out animations for Tech Mechs that touch water.
- Custom graphic set support. Above all else, I'd like Tech Mechs to have a custom community like Lemmings does, and I want to make it as easy as possible for users to make their own graphics. Right now, it is possible, but it involves manually making very specific text files containing metadata for the objects in the graphic set.
- Improved UI for the level editor. While my level editor works, it is NOT user-friendly at all, and I'd like to change that, but it will be an extremely demanding job.
- Add in voice or text chat in multiplayer mode. Because you have to work together and cannot see each other's skills, communication is essential for multiplayer, and thus far it doesn't have that. I'd really like to change that, but it will be a TON of work.
- (Possibly) Allow for more than 2p multiplayer. While this would open even more puzzle potential, I'm afraid allowing for more than 2 players in cooperative multiplayer would not only make it too confusing but would also cause the game to lag due to all of the data being transferred through the server.
- (Possibly) Add competitive multiplayer. While it would be cool and (relatively) easy to make since a lot of code can be reused from the cooperative multiplayer, we already have Lix, so I'm leaning towards passing on this one.